The patch on top does not close the door below

The patch on top does not close the door below

The software ecosystem has an inventory problem and a delegated trust problem, and the week showed both at once.

Updating the main application no longer guarantees security.

GitLab (CVE-2026-97229, CVSS 10) carries an unauthenticated remote code execution flaw in the CI/CD pipeline, and it is under active exploitation.

The problem, as Alpine Linux found, is that the GitLab patch does not fix the underlying Ruby interpreter. If the operating system keeps a vulnerable Ruby, the door stays open.

PHP2Shell shows an identical scenario, which proves the attack surface includes invisible dependencies that teams assume belong to someone else.

If the pattern can be manipulated, the attacker gets the interpreter to run whatever he writes instead of only searching.

CISA added it to the KEV catalog on October 29 and gave federal agencies until Sunday to close it (Source: securityweek.com).

That detail turns a routine advisory into an inventory problem. The question is no longer whether your GitLab is updated but which Ruby version is running it.

The week brings the same pattern somewhere else.

PHP2Shell still has no complete mitigation, and PHP warns that updating is all that is left (Source: securityweek.com).

The flaw affects versions from 5.4 onward, carries CVSS 9.2, and industrial vendors are checking product by product whether they embed the interpreter (Source: securityweek.com).

Blind trust in third parties has become the most profitable vector.

Polymarket lost 2.7 million dollars in minutes because a compromised external analytics script hijacked sessions straight from the user's browser.

In parallel, the official Claude Code extension shipped trojanized code from the Cursor marketplace for eleven hours, opening reverse tunnels through SSH keys.

The attacker does not need to break the company's code because compromising the middle piece or the official distribution channel is enough.

In all three cases the flaw lives in a piece the team does not consider its own. The application on top gets patched and the case is closed.

When the channel is the attack

On October 29, the official Claude Code extension 2.1.313 was served trojanized from the Cursor marketplace for eleven hours (Source: microsoft.com).

The version that reached users was not the one the vendor had signed, and it added an attacker SSH key and opened a persistent reverse tunnel to his infrastructure.

A reverse tunnel is a connection that leaves the compromised machine and stays open. The attacker does not need to get in afterward, because the door is already open from the inside.

Up to 5,000 users were exposed in that eleven-hour window. Cursor rebuilt the marketplace and rotated the affected keys (Source: microsoft.com).

What stands out is not that a package gets compromised but that the compromise happened in the channel the tool itself uses to distribute, the one the user installs because he trusts the brand.

That same day, OpenAI confirmed another incident in the same direction. A shared ChatGPT link could run code inside the recipient's authenticated session and exfiltrate conversations that had never been shared (Source: thehackernews.com).

The fix was server-side, with no user action, so the flaw did not depend on what the victim did but on what the service allowed a link to do.

The week brings a third case along the same line.

TeamViewer fixed CVE-2026-111585, CVSS 8.8, in clients earlier than version 15.83 (Source: thehackernews.com).

The flaw is an overflow when negotiating screen size. It allows code execution in the Windows viewer with the default configuration; accepting the session is enough.

The direction of the attack is what matters. The compromised remote host attacks whoever connects to it, not the other way around. The machine you call to fix something may be the one that compromises you.

The traditional connection paradigm is failing too.

The other side

Not every week is about patching.

Polymarket lost about 2.7 million dollars in minutes because the DebugBear analytics script was compromised and hijacked sessions to drain wallets (Source: securityweek.com).

The platform paused trading for an hour and promised refunds, and the vector was not a flaw in its code but a third party serving a script on its page.

In all four cases, the weak link was outside the company's own inventory.

My reading

My reading is that the hole is in management, not in patches.

The team knows which applications it has and does not know what holds them up underneath, which channel distributes them, which hosts they connect to, or which scripts they load in the user's browser.

Tool choice is no longer decided only by what the tool does but by who distributes it and which signature backs it.

A marketplace that rebuilds its catalog in eleven hours shows reaction capacity but does not prove the next package will arrive clean.

And remote access works the same way, because if the host you connect to can attack you, the connection policy has to assume the other end is hostile until proven otherwise.

What to look at?

• The interpreter version. Check on every GitLab host which Ruby runs it and whether it is on the fixed version list. With PHP, the same: the application patch does not cover the interpreter.
• Exposed CI/CD endpoints. Check whether the pipeline accepts requests from outside the internal network. GitLab runs code by design, so a flaw there does not need a victim to click.
• Installed extensions. If you have Claude Code 2.1.313 or anything that came from the Cursor marketplace on October 29, rotate the machine's SSH keys and look for active reverse tunnels.
• Remote access and third-party scripts. That viewer should not have permissions over the internal network. And any embedded analytics or tag manager is attack surface, so if you cannot pin its version, log which domain serves each one.

How would I test it in my lab?

I would set up GitLab in a container with the system Ruby on the vulnerable version and another with the fixed one. I would send the same malicious request against both and watch each log.

If the first executes and the second does not, I have proof that the GitLab patch is not enough on its own. If both execute, the problem is in another layer and I have to keep going down.

Then I would install an extension from a local marketplace and watch which keys it writes to the system. It is cheap and it says a lot about what the user accepts without reading.

It is a test that fits on any laptop with Docker. I would run it before closing the CISA advisory on my own network.

Action plan

• Identify the underlying interpreter: Check on every host which exact version of Ruby, PHP or another base language runs the main application.
• Limit CI/CD exposure: Block external requests to the pipeline endpoints if they are not strictly necessary for operations.
• Audit external scripts: Log every third-party domain loaded on your site; a compromised analytics tool grants full access to authenticated sessions.
• Isolate remote support: Viewers used to connect to clients or third parties should have no permissions or visibility over your internal network.
• Validate in the lab: Spin up Docker containers with vulnerable and patched versions of the base system to empirically check whether the application update stops the exploit.

Originally published at https://sammideblas.com/notas/the-patch-on-top-does-not-close-the-door-below

Si has leído hasta aquí... reacciona y comparte -> "la seguridad y la defensa en la era de la IA es cosa de todos los que la usan" ¿No Crees?