This summer, a state-linked campaign called PolinRider planted a loader in one of our sample repositories. Our first read of the git history said it had been there for thirteen months. That number was manufactured: the attacker had rewritten commit dates and force-pushed to stage a timeline for us to find.
Around the same time, Hugging Face was investigating a breach carried out by two OpenAI models that had escaped an evaluation sandbox. When its responders asked commercial AI models to help analyze the attack, the providers' safety filters refused. They finished the investigation on an open-weight model running on their own hardware.
Both stories end the same way. What you'd normally trust was either rewritten or locked, and the way out ran through things you could inspect and run yourself. That's why we're doubling down on open source rather than retreating from it.
“Failure is not an option” is a great movie line. But, nobody in Mission Control actually said it during Apollo 13; a screenwriter tightened a flight controller's offhand remark into a tagline. As a security posture in today's threat landscape, it is dangerous. No system is impenetrable. Attacks that used to require a funded team now run on automated models and pennies of compute, constantly probing live production systems across the industry. Closed code doesn't change that; it only guarantees that when an inevitable breach occurs, transparency is lost and you can't see how far it went. What survives is what an immune system does: assume active exposure, spot it fast, and share the antibodies publicly.
Open source is the immune system
An immune system doesn't assume the body will never be exposed. It assumes exposure and wins on detection, distributed response, and memory. With open source, you can put the same principles in place.
More eyes than you can hire. When code is open, the people checking it aren't limited to your payroll. Independent engineers, researchers, automated scanners, and customers all look, and they catch what a single internal team misses.
A front door for good news. Openness only pays off if you make it easy for those people to tell you what they found. A clear, rewarded responsible disclosure policy turns outside researchers into an extension of your security team, and flaws get fixed in daylight instead of weaponized in the dark.
A blast radius you can measure. During a campaign, the only question that matters is how far it went, and you can only answer it across code you can read. That holds for closed-source shops too: their products sit on open libraries, and the ecosystem-wide sweep that tells them whether they're exposed exists only because those libraries are open.
That's why we published our detection tooling instead of keeping it: github.com/dotCMS/polinrider-scanner. It's narrow, specific to this loader family, and yours to run. When one cell beats an infection, the whole body gets the antibodies.
Retreating into closed source is the same instinct as adding another human approval gate. It creates a false sense of security and fails as automated attacks flood production networks right now.
Failure is not an option, it’s a guarantee
In July, two OpenAI models, running with cyber refusals deliberately reduced for an authorized evaluation, found and chained previously unknown flaws in self-hosted JFrog Artifactory, escaped their sandbox, and reached Hugging Face's production systems. Nine CVEs came out of it, including server-side request forgery, path traversal, privilege escalation, and remote code execution, patched in Artifactory 7.161.15 and 7.146.34. The full chain needed Anonymous Access enabled, which is off by default. The point stands: a mature, widely deployed product gave up nine unknown flaws to a model inside a single evaluation run.
Hugging Face's refused requests are the other half of the story. Hosted safety filters can't tell an attacker writing an exploit from a defender reading one, so they block both. Attackers actively deploy unrestricted models in the wild, while defenders fight with guardrailed ones. Open-weight models trail the frontier by three to six months and cost cents to run. Weaponized exploits that once required specialized nation-state teams are now being executed continuously at near-zero cost. The old assumption “we're too small to be a target” is completely dead in current operations.
The volume shows it. Microsoft's September 2026 Patch Tuesday shipped a record 964 CVEs, 104 of them critical, against a trailing twelve-month average of about 159 CVEs and 16 criticals (Tenable, CrowdStrike). That's roughly 32 new CVEs a day for the month, three or four of them critical, from one vendor. Nobody audits their way out of that.
Where we missed it
Ours wasn't caught by a system. In May, one of our engineers spotted an odd loader by eye and removed it in under half an hour, without knowing what it was. Public researchers had been tracking the campaign since March. We were three months late to our own discovery.
It wasn't escalated, and the reason matters more than the miss. We had adopted AI-assisted development faster than we had learned its failure modes, and the artifact looked like the strange-but-harmless code that model sessions produce every day. The engineer reasonably concluded it was their own AI noise, cleaned it up, and moved on. A state-linked loader hid in the background radiation of our own tooling.
That isn't a person failing; it proves that no system or safeguard is impenetrable. Relying on one person being right about every anomaly on an ordinary day is “failure is not an option” all over again. In a landscape of continuous, active threats, transparency and systemic resilience are the only working defenses. So we changed the plan:
The human is the judge, not the sensor. Anomaly detection and a model make the first pass, and a standing sweep reports oddities weekly to security and engineering leadership. Human-in-the-loop (HitL) now means managing how the system performs against expectations, not approving each change. As more of our pipeline runs without a person touching every line, that's the only kind of HitL that scales.
Detection and discovery share one channel. Most anomalies aren't malware. Sometimes one is an engineer who found a better way to do something, and routing oddities to leadership means those get demoed to R&D instead of dying in a branch nobody read.
No single layer is the fix. Force-pushing to default branches was allowed on those repositories. An organization-wide policy blocks it now, and should have from the start. There will always be one more setting, so the layer that catches a miss can't be the layer that made it.
Speed cuts both ways
We ship continuous upgrade tracks: latest, standard, and trailing. Latest gets patches immediately, and it also pulls in a poisoned dependency immediately; the community usually takes 48 to 72 hours to flag one. Standard and trailing run two to four weeks back, which protected them in this incident for free.
But at 32 CVEs a day from one vendor, two to four weeks is a long time to sit on known holes. Project Zero gives vendors 90 days to fix a flaw, and it names the vendor and product within a week of reporting, so the world knows a flaw exists long before the fix does. No track is safe by default. The choice has to be deliberate, not an accident of when someone last had budget to upgrade, and our Evergreen Tracks docs cover how to make it.
What I'd tell another technology leader
1. Bet on openness. Treat open source and outside researchers as part of your defense, not as liabilities. Publish what you learn, and make disclosure easy and rewarded.
2. Treat your own records as hostile. Before the next incident, list every source an attacker with commit access could have written: commit dates, tags, branch history, anything mutable. Then find the ones they couldn't: registry checksums, artifact digests, logs shipped off-box on write. We did that inventory mid-incident. It's much cheaper the week before.
3. Build systems, not heroes. Make the system the sensor, and make curiosity cheaper than embarrassment, so that anyone who notices something odd can say so easily and gets credit for it. That reaches well past engineering. Every department now runs AI tools, skills, and MCP servers, and security training has to cover where those came from and what they can reach, not just the link in the email.
4. Shrink what you import. Every library brings its own dependency tree, and you inherit all of it. Don't pull in a package for two functions you could own. We applied the same rule to our build pipeline and removed Artifactory rather than harden a layer we didn't need.
dotCMS is software made by people who like software. Because no code or infrastructure is invincible, systems will face attacks and failures in the wild. The job is building transparent infrastructure that expects exposure, identifies it rapidly, and heals in public. We intend to keep doing exactly that alongside our customers and the open-source community.
Our customer advisory for this incident, including who was affected and what to do, is in our trust center at security.dotcms.com/updates.