- Collabora released a fix for a Nextcloud add-on flaw on September 11. Administrators reported attacks from September 10, and the CVE and advisory came on October 14.
- The sources do not say whether attackers used the fix. The case shows that a process keyed only to CVE IDs has no signal while the label is missing.
- Check for the built-in CODE server app, upgrade to 26.4.303 or later, and track vendor releases without waiting for CVEs.
Many security teams wait for a CVE number before they act. A CVE is the public ID that scanners, tickets and audits are built around. A Nextcloud flaw shows how little signal that habit gives while the ID is missing. The fix existed. The label did not.
What happened
Collabora's GitHub advisory, GHSA-g3vx-3m76-fghh, covers richdocumentscode. This is the optional Nextcloud app that bundles Collabora's document server, called the Built-in CODE Server. A crafted request to the app's proxy.php endpoint can make the server run a command with the web server's permissions. The flaw is now tracked as CVE-2026-110447.
Collabora fixed it in release 26.4.303. The advisory says standalone Collabora Online servers are not affected. BleepingComputer adds, citing Collabora, that Docker, RPM/DEB and Nextcloud All-in-One deployments are also unaffected.
How the flaw works
The bundled server lets Nextcloud users edit office files in the browser. The flaw sits in the code that starts that server. An attacker sends a request to proxy.php, and text inside it runs as a command. This is called command injection.
There is a catch. Exploitation needs the bundled server to be stopped. Collabora names a container restart, an upgrade or a crash as the moments when that happens. Routine maintenance can therefore create the opening. BleepingComputer reports that no login or user action is needed.
Switching the app off does not help, Collabora says. The fix is version 26.4.303 or newer, or removing the app entirely. Nextcloud 29 and older have reached end of life. Their users should upgrade Nextcloud or remove the app. The advisory also says this is a separate path from CVE-2025-66208, so the earlier fix does not cover it.
Attacks reported before the CVE existed
The dates matter. BleepingComputer reports that Collabora committed the fix on September 9 and released 26.4.303 on September 11. It published the advisory and CVE on October 14, more than four weeks after the release.
Administrators reported attacks dating back to September 10, according to BleepingComputer. That is the day after the fix commit and the day before the release. The attackers planted PHP webshells, which are small scripts that give remote control. They then searched for password databases, password manager files and cryptocurrency wallets.
The sources do not say how the attackers found the flaw. They do not say whether anyone worked from the published fix. A community warning on October 3 urged administrators to update. BleepingComputer reports that the missing CVE ID made it harder for them to pinpoint the problem and plan a defense.
Nextcloud's response, and what cannot be tested
Nextcloud told BleepingComputer that Collabora reported the bug in mid-September and that an update then reached users through the app store. It said the delayed announcement gave people time to install that update. It also said it had not seen exploitation on a broad scale.
That last claim cannot be checked. Administrators reported intrusions from September 10, and the number of affected systems is unknown. The BleepingComputer report gives no count of affected systems.
Why CVE-only processes leave a gap
Many defensive tools key on CVE IDs. Here the ID arrived on October 14, after the fix was out and after attacks were reported. The lesson is about process, not about how this attack began. A team that acts only on the ID has no signal while the label is missing.
Second Security's study of open-source flaws gives wider context. It is not an explanation of this case. The firm found the median wait between a public fix and a CVE was 39 days in August, against 5.1 days in January.
The researchers suggest that more AI-assisted vulnerability finds are straining CVE processing. They also found that public exploit code often appeared within hours of a fix, days before the CVE. Collabora gave a similar reason for its own delay. It pointed to backlogs at GitHub's CVE processing, which it said were strained by AI-driven security reports.
The Collabora case is one incident. Second Security's figures are one study. Together they point to a process question worth testing in your own organisation.
What leaders should ask
Start with exposure. Ask whether any Nextcloud server uses the built-in CODE Server app. If so, confirm it runs 26.4.303 or later, or is removed. Check that the Nextcloud version itself is supported.
Then look back. Ask the team to review web logs for odd proxy.php requests since September 10. Ask them to search for unexpected PHP files. If anything turns up, treat the passwords and keys stored on that server as possibly exposed and plan to rotate them.
Finally, review the process. Ask which vendors' releases the team tracks directly, and how quickly a patch goes in when no CVE exists. If the answer is that the team waits for the ID, the same blind spot applies to the next flaw.
A fix without a CVE is still information. Teams that treat it that way do not depend on the label to start work.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Collabora Online (CollaboraOnline GitHub security advisory GHSA-g3vx-3m76-fghh).
