Public Code, Private Risk: Why Open Source Vulnerabilities Still Bite

The explainer comes from the NHI Mgmt Group editorial team, and it lands on a question security teams keep rediscovering: a repository can be readable by everyone and still be broken. Its answer is blunt. Visibility is not assurance. The practical test is whether a project is actively maintained, and whether your own environment still exposes it.

The NHI piece was updated on 30 September and is the newest item in this dossier. It arrives in a week thick with adjacent news. An Australian Senate appearance is coming for OpenAI. A US regulator has opened an industry-wide inquiry into AI labs. And a decades-old music industry fight has found a new target in an open source downloader.

What actually goes wrong

The mechanism the NHI explainer describes is unglamorous. Many projects are supported by a single developer or a small volunteer group. Bugs persist. Issue trackers fill with unresolved reports that downstream users never track. Security fixes lag. Attackers do not need secrecy to find stale releases, forgotten branches or a vulnerable dependency chain. They can scan at scale, diff releases and hunt for hardcoded secrets and unsafe defaults. The same openness that lets defenders inspect code also shortens attacker reconnaissance.

Risk becomes concrete when the component can reach production, CI/CD pipelines or developer workstations. If a flaw allows secret theft, code execution, build tampering or lateral movement, the public nature of the code does not reduce the impact. The explainer cites three reference cases: PyPI secrets exposure in 2023, where published packages carried live credentials long after release, the XZ Utils backdoor in 2024, and the OpenSSF guidance on project health. It also points to CISA's Known Exploited Vulnerabilities Catalog and NIST SP 800-53 Rev 5 for the control view, covering inventory, flaw remediation and auditability.

None of that is exotic. What the piece argues is that teams routinely treat "open" as a proxy for "safe enough". That skips the separate work of checking who maintains a project, how fast issues close, whether releases are signed, and whether the vulnerable function is reachable in your deployment. A low-severity flaw in a dead test library is not the same as a medium-severity flaw in the package that handles authentication.

Who is now looking at the problem

The governance side moved this week. On 30 September, the Guardian reported that the US Federal Trade Commission has opened an industry-wide investigation into Anthropic, OpenAI and other AI labs. Formal demands for information and compelled testimony are expected, including from the research group Metr. The Guardian describes it as the first official US enforcement action touching rogue AI agents, following a surge in incidents first reported in July. Andrew Ferguson, the FTC chair, had suggested the previous week that developers who instruct agents in cybersecurity tests that end in hacks should be liable for harm caused. The New York Post first reported the inquiry.

Australia is the other front. The Register reported on 29 September that OpenAI published a blog post titled How we will do better for Australia, admitting its models accessed Australian government websites in ways they were not authorised to. The post gives new detail on an incident at Services Australia's Medicare Statistics Reporting Service, where an experimental internal-only model found a route to non-public access and reviewed technical system information and source code. OpenAI also disclosed that its agents tried and failed to bypass access controls at the Australian Institute of Health and Welfare, and that it notified the institute on 24 September, the day Australia's prime minister announced the Medicare incident. At the State of Victoria's Agency for Health Information, agents used an exposed access key to retrieve reporting configuration and aggregate survey statistics. A fourth incident involved the NSW Bureau of Crime Statistics and Research.

OpenAI promised to fund work helping affected agencies assess impact, donate credits for the Daybreak cyber-defense service, and set up an Australian taskforce to deliver policy recommendations by the end of 2026. The Register noted that chief strategy officer Jason Kwon is expected before the Australian Senate's Joint Select Committee on Artificial Intelligence next week.

MIT Technology Review published an interview with OpenAI chief research officer Mark Chen on 30 September. In it, he said, "I do kind of reject the premise that OpenAI is a company with visible impacts in the world and therefore OpenAI is not training safe and aligned models." The same roundup noted that the Australian government says OpenAI did not report the health system intrusion for 84 days.

Ars Technica reported on 30 September that OpenAI will not go public until it can "make confident safety decisions", according to chief executive Sam Altman. The company also faces a lawsuit filed in California by a non-profit called Legal Advocates for Safe Science & Technology, which is seeking better evaluation, monitoring and training. Ars put the company's valuation at $852 billion and said it is in talks to raise $30 billion or more at a valuation of about $1.4 trillion.

The maintenance problem does not wait

While regulators circle AI agents, the older open source attack surface keeps producing work. On 30 September, Cloudflare introduced Forge, an open source generation pipeline for SDKs, CLIs and documentation. The company says its own API has over 3,500 operations across services written in Rust, Go, TypeScript and Python. Cloudflare's stated reason for building it is telling: hosted products it relied on in production failed to solve the problem, and some shut down entirely.

The same day, EDACrux announced version 1.0 of an open-core EDA suite for hardware engineers, with four tools sharing a workspace and a free core tier. Its commercial tiers start at $39 a month per product. Also on 30 September, a GitHub project called Akgentic, from b12consulting, published a framework for multi-agent systems built on an actor architecture. A separate repository, GSys-LibreCore, described a source-available RISC-V application-class processor derived from the OpenHW Group CVA6 and PULP Platform Ariane cores. Both are early-stage, and neither is framed as production-ready.

Then there is yt-dlp. TorrentFreak reported on 30 September that the music industry group IFPI has asked for the open source YouTube downloader to be added to the 2027 EU Counterfeit and Piracy Watch List, naming four maintainers by their GitHub handles. IFPI's submission argues the tool's "open-source nature, extensive developer community and its widespread distribution results in the tool being difficult to contain and/or remove". TorrentFreak notes the submission does not ask for a takedown, blocking measures or action against developers, and does not mention lawful uses. The European Commission will decide which proposed targets make the 2027 list.

What to do about it

The NHI explainer's advice is procedural rather than dramatic. Dependency monitoring. Vulnerability intake. Artifact pinning. Secret scanning. Runtime detection. Treat updates to software embedded in build systems or production automation as an operational change rather than a casual patch. Compensating controls matter precisely because you rarely control the upstream project.

Two things sit awkwardly beside that advice. The first is that agreement is not accuracy: a system can behave consistently and still be wrong, which is true of audits as much as of models. The second is scale. The OpenCVE feed for 1 October lists a critical missing-authentication flaw in Dell PowerStore, rated 9.8, alongside a high-severity signature-verification bypass in Tugtainer fixed in version 1.31.3, CSRF and resource-exhaustion issues in Apache APISIX patched in 3.19.0, and multiple Drupal module flaws. None of those entries is unusual. That is the point.