Five Timeout::Error events from one client in thirty minutes, all coming from the OtherMarkup renderer while it chews on .org files. That's the threshold GitLab's security team suggests for spotting attempts against CVE-2026-110264, and I can't stop thinking about it. Most of the GitLab instances I've administered over the years never rendered a single Org-mode document on purpose. Every one of them would have rendered one for an anonymous stranger, though, and that turns out to be the whole problem.

Here are the facts, briefly, because you need them before anything else. On October 21, 2026, GitLab shipped an out-of-band critical patch for CE and EE: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. The bug is an integer overflow (CWE-190) in how Ruby's Onigmo regex engine handles patterns that attacker-controlled Org content can shape via org-ruby. A size calculation wraps around, memory gets touched where it shouldn't, and under the right conditions an unauthenticated user gets code execution on the server. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, so it scores a flat 10.0. The affected range goes back to the 7.0 line. GitLab.com and the listed Dedicated versions are already fixed. If you self-host, stop reading and upgrade, then come back. And check that Puma and Sidekiq actually restarted on the new build, because a package that's installed but not running hasn't fixed anything.

What bothers me is where the hole was, more than the overflow itself. Memory bugs in C regex engines are an old, familiar kind of trouble, and I'll leave the Go crowd to feel smug about bounds checks for a sentence or two. What I can't shake is that a code forge, a tool whose job is holding our source and our deploy keys, was running a niche document renderer for unauthenticated visitors, and that path ran straight into native code. Nobody on a typical platform team ever sat down and decided that anonymous users should be able to make the server compile regexes out of Emacs notes. It came bundled with "we render your README nicely," and that sounded harmless, and for years it was.

The strongest objection deserves a fair hearing, because I half agree with it. You can't predict which parser will have the next bug. Rip out Org-mode and next quarter it's AsciiDoc, or the Markdown sanitizer, or the image thumbnailer. The people who live in Org files are real users with real needs, and a vendor that ships the bare minimum ends up shipping a worse product. Patching is the only fix that scales, and GitLab patched across seven branches within the same release. Fair. If your takeaway from this is to strip every feature down to a plain text area, you'll lose that argument to your users, and you'd deserve to.

My answer is that it doesn't have to be all or nothing. It comes down to who gets to reach the renderer. A renderer that only authenticated project members can trigger is a bug waiting for an insider. A renderer that any network client can trigger without logging in is a bug waiting for the whole internet, and that's exactly what the AV:N and PR:N in the vector string are telling you. Niche formats on public, unauthenticated paths should be opt-in per instance, and they should show up as a line in the admin panel you can switch off. Right now they're an emergent property of the dependency tree. The detection guidance makes the cost concrete: a native [BUG] crash with frames like onig_compile or match_at is the noisy outcome, and GitLab says plainly that a successful exploit can be quiet. You can't monitor your way out of a path you didn't know existed.

Now turn that around and point it at our own code, because PHP apps are full of the same pattern. We build PCRE patterns from user input in search filters, highlight helpers and routing tables. We ship BBCode and Markdown parsers, wiki syntax extensions and "paste anything" previewers, often on pages that don't require a login. The PHP side gives you decent guardrails: preg_quote exists, pcre.backtrack_limit exists, and the engine has had years of hardening. Guardrails only help on code paths somebody remembers are there, though. I'd bet a decent coffee that most mature Laravel or Symfony codebases have at least one public endpoint whose rendering pipeline nobody on the current team has read.

So yes, patch first, preserve your Workhorse and Sidekiq logs before you get too eager with restarts, and rotate tokens if the instance sat exposed and anything in the audit log looks off. Then spend one afternoon on the less glamorous job: list every format and every user-influenced regex your systems will process for someone who hasn't authenticated, and ask whether each one earns its place. It's a short list to write. Deleting entries from it is where the real argument starts.

Which brings me to what I'd like to hear from you. When you last audited a self-hosted tool or your own app, did you find a renderer or parser exposed to anonymous traffic that nobody could explain the need for? And when you proposed turning it off, who pushed back, and were they right?