Theo on Security Vulnerabilities, Stolen API Keys and AI

A wave of security news makes it feel as though everything has been hacked. But that framing is misleading: several different events are happening at once. Some are disclosed vulnerabilities in widely used software; others are reported attacks against services. Both matter, but they are not the same event.

The vulnerability side includes issues involving Node.js, GitLab, PHP and QUIC. The attack side includes Railway and OpenCode. I am especially worried about the latter and about important details that can get lost when all these stories are bundled together.

LiteLLM needs its own distinction. I describe it as a supply-chain attack involving a hijacked GitHub Actions workflow and a malicious published version, rather than a flaw in the ordinary codebase. I will leave it aside here so I can focus on the other examples.

During the recording I also saw an Oracle vulnerability report, which I placed with the disclosed CVEs rather than the attacks. A CVE gives a vulnerability a shared identifier so organizations can track and discuss a known issue across products and distributions.

The October 21 Node.js security release illustrates the process. It lists fixes for supported release lines and dependency issues, including c-ares and OpenSSL. Security releases give users a route to update; a published identifier does not itself mean that every installation was attacked.

I also mention a certificate authority compromise and the need to update software that trusts affected certificates. The important operational point is to follow the relevant vendor guidance and make sure browsers, runtimes and other dependencies receive the fixes they need.

Coordinated disclosure allows maintainers and distributors to prepare fixes before details become public. But once a patch is visible, there can be a dangerous interval before everyone installs it. Attackers can study the change while users remain on the older version.

Many compromises exploit vulnerabilities for which fixes already exist but have not been deployed. Keeping operating systems, browsers, applications and dependencies updated helps shorten that gap. I call the time during which software can be attacked its vulnerable window.

That window depends on several factors: how visible the underlying flaw is, how long it takes to deliver and install a fix, how difficult exploitation is, and what access it grants. Patching a server under one operator's control is different from getting every user to update an installed application or redeploy a library.

I worry that agents can make it easier to inspect many commits and identify security fixes, and that capable models may speed analysis of old versions. This is a prediction about the changing threat, not a measurement of each incident. It makes deployment speed and the consequences of a successful exploit even more important.

For the PHP issues, I show a warning from the FBI Cyber Division. The displayed post says two vulnerabilities could allow remote code execution and urges organizations to update affected installations, inventory exposed systems and monitor for suspicious processes. It also advises taking affected systems offline if an immediate update is not feasible.

The displayed warning identifies CVE-2026-109618 and CVE-2026-109619. I describe them as serious and discuss a report that patched container images were released before the coordinated embargo ended. According to the report I show, the PHP Foundation said the early release exposed fixes while other distributors were still preparing updates.

My concern is that early disclosure leaves defenders less time to deploy updates before an attacker can examine the fix. The order and timing of disclosure matter, particularly if automated tools make that analysis faster. Separate teams discovering the same weakness also make it harder to assume that only the first reporter knows about it.

I say the PHP issues were found using an earlier model and that Wiz independently reported them. My broader point is that capability does not remain confined to one researcher or one model. Independent discovery increases the importance of coordinated disclosure and prompt patching.

I also object to using the share of all websites running PHP as a direct measure of user impact. A count of sites and a count weighted by traffic answer different questions, and abandoned sites can influence the former. My own open tabs are only an illustration, not a representative measurement of the web.

That does not make neglected sites harmless. I remember an old WordPress site I built for a relative that was compromised after I stopped maintaining it. Abandoned sites, systems whose maintainers have left, and government services can remain exposed even when they are not among the sites I use every day.

Turning to OpenCode, I describe an incident involving third-party API keys users had supplied through its dashboard. I say affected developers reported unauthorized consumption and account suspensions, with charges ranging from hundreds to thousands of dollars. These are reports I discuss in the video; the scope of exposure needs to be checked against the provider's incident notice.

I say OpenCode was working with providers on refunds, reinstatement and key rotation. A stolen key can be useful even if it is revoked soon afterward, which raises the question of why someone would seek a large burst of inference for only a short time.

Railway's disclosure, shown on screen, says an unauthorized party may have accessed encrypted customer environment variables and obtained some decrypted contents. Those variables can contain API keys, database credentials and other secrets. The notice says its investigation was ongoing and recommends precautionary action for users.

I had services on Railway and was frustrated that deployments were unavailable while I wanted to rotate variables and redeploy. I separate the credential incident from the deployment outage and criticize Railway's reliability. My judgment about the outage's cause is my own assessment, not a finding established by the disclosure.

Railway had also been a sponsor, and I say my criticism could affect pending ads. I like aspects of its pricing and storage, but the outage made me reconsider where to host important software. The immediate problem for users was being unable to restore deployments and replace credentials as quickly as they wanted.

Why steal keys that will soon be revoked? I consider possible uses, including fraud and other attacks, then advance my own hypothesis: large quantities of inference could be used to generate training data for model distillation. The video does not establish that this was the motive or identify the perpetrators of these incidents.

By distillation I mean using examples of a stronger model's behavior to help train another model. Data showing how an agent carries out complex tasks with tools can be valuable and may not exist in large quantities as ordinary web text. A lab seeking that data may therefore want many model responses.

I argue that model providers restrict access when they suspect customers are collecting data to train competing systems. I discuss account restrictions, identity checks, usage tiers and regional access controls as possible barriers. My interpretation of providers' motives combines safety concerns with commercial incentives; it is my opinion.

I speculate that stolen keys could be attractive because they temporarily provide inference billed to someone else's account. I also admit that I do not monitor my own OpenAI spending as closely as I should and checked it after the Railway incident. This is a theory about incentives, not evidence tying a particular lab to these attacks.

I go further and suggest that demand for model outputs could make platforms storing API keys more attractive targets. I do not present evidence proving that the Railway or OpenCode incidents were conducted for distillation. Other motives are possible, and the exact attribution remains an open question in the account presented here.

The broader risk is that secrets stored with a platform can have value beyond the platform itself. Keys can incur charges or provide access to other systems before revocation. I expect credential exposure to remain a serious concern, regardless of the eventual motive attributed to any one incident.

I also criticize what I see as model refusals that make some legitimate security work harder. That is my experience and assessment. Whether a provider should restrict particular users or uses is a separate question from how organizations protect their own credentials.

Finally, I stress that the PHP vulnerabilities and the Railway and OpenCode incidents should not be assumed to be related merely because the news appeared around the same time. Keep software updated, monitor relevant incident notices, and protect, separate and rotate API keys so they can be revoked quickly if exposed.