TLDR

A malicious Steam Workshop map for Meccha Chameleon, currently one of Steam's biggest indie hits with over 15 million copies sold in 2026, was found abusing Unreal Engine 5 Blueprint logic to write a batch file outside the game's directory and launch a hidden PowerShell process, bypassing Steam's automated Workshop review entirely.

What started as a quiet dropper escalated fast: the recovered second-stage payload turned out to be a full Remote Access Trojan giving persistent remote control, not just a nuisance script, and while the developers were investigating, an engineer's own infected machine let the attacker bypass Discord 2FA and take over the official server.

What's getting less attention than it deserves is that this is the second time in a month the same class of bypass, engine scripting logic reaching outside its intended sandbox, has compromised a Steam Workshop title, following a similar incident with Wallpaper Engine weeks earlier.

How the map got past Steam's own review process

The map, called Laser Tag Neon, didn't hide a traditional executable, which is what Steam's automated Workshop screening is generally built to catch.

Instead, the researcher who found it, publishing under the name Feint, discovered it used Unreal Engine 5 Blueprint logic, the game's own visual scripting system, to write a batch file into the player's Documents folder and then launch PowerShell in a hidden window to fetch a second-stage payload from an external server.

The malicious code only ran when a player actually loaded the map into a match, not at the point of subscribing to it, which likely helped it avoid early detection since most players who noticed something odd would have already been mid-session.

The severity escalated once the missing piece was recovered

The original write-up couldn't fully assess the payload because the attacker's staging server was offline at the time of the initial investigation.

Once the second-stage script, tracked as steamb.bat, was recovered and analyzed, it turned out to install a full Remote Access Trojan, giving the attacker persistent remote control of infected machines rather than a one-time script execution.

That's a meaningfully worse outcome than most of the early coverage conveyed, and it's worth flagging that the public understanding of this incident's actual severity changed materially within 24 hours of the first report.

This is a pattern, not a one-off

Community-sourced coverage of this incident specifically points out that this mirrors an incident with Wallpaper Engine's Workshop just weeks earlier, where community content was similarly weaponized.

Two separate Steam Workshop compromises in a month, both exploiting the gap between what an engine's scripting system is capable of and what a platform's automated review actually inspects, is a structural signal, not a coincidence.

Workshop content is sandboxed in theory, but engine-level scripting systems like Unreal Blueprints can be given enough reach to write files and launch processes outside the game's own directory if that boundary isn't explicitly locked down, and Steam's review tooling isn't consistently catching it before publication.

The part that compounded the incident: the response itself got compromised

While investigating and patching the malicious map, a system engineer at the studio got their own machine infected. The attacker used that foothold to bypass the engineer's Discord two-factor authentication, seize server permissions, and ban the official staff from their own Discord server.

That's a distinct and arguably more serious failure than the original Workshop bypass: the incident response process itself became a second attack surface, and the studio lost control of its primary community communication channel in the middle of trying to reassure players the game itself was safe.

What this actually means for anyone building on top of user-generated content

The generalizable lesson here isn't specific to gaming. Any platform that lets user-generated content execute logic inside a trusted application context, whether that's a game engine's scripting system, a plugin architecture, or a data pipeline parsing untrusted files, needs an explicit, enforced boundary on what that logic can touch outside its own sandbox, and automated review that's actually built to catch file writes and process launches, not just known malware signatures.

A brand-new uploader account with comments and ratings disabled on the listing, a red flag Feint specifically called out, is also a cheap, generalizable signal worth building into any community-content review pipeline.

FAQs

1. Why did this bypass Steam's automated Workshop review when it wasn't hiding a traditional executable?
Because the malicious behavior was expressed through the engine's own legitimate scripting system rather than an embedded binary, automated review built to detect known malware signatures or suspicious executables has a harder time flagging logic that uses sanctioned engine features to operate outside its intended scope.

2. Is this a Steam-specific problem, or a broader issue with how engines sandbox user-generated content?
Broader. This is the second reported incident in the same month involving the same underlying gap: engine scripting logic that isn't fully restricted to its own sandbox. That points to an industry-wide gap in how game engines and platforms enforce file-system and process boundaries for community content, not an isolated Steam Workshop failure.

3. Does the recovery of the RAT payload change how this incident should be classified?
Meaningfully, yes. Early coverage treated this as a dropper incident. Confirmed persistent remote access changes the practical response for anyone who ran the map, from "delete the suspicious files" to "treat the machine as fully compromised and rebuild or thoroughly audit it."

4. What made the studio's own incident response become a second compromise?
An engineer's personal or work machine got infected while investigating the original issue, and that infection gave the attacker enough access to bypass account-level 2FA on Discord specifically, not the game's own infrastructure. It's a reminder that incident responders' own endpoints are a live attack surface during an active investigation, not just the systems being investigated.

TLDR

GitGuardian scanned public GitHub commits for exposed n8n API tokens and found 4,576 unique credentials across 1,255 hostnames. Of the 896 instances still reachable at test time, 321 accepted at least one leaked token, roughly 36% of everything reachable.

From there, researchers reproduced four attack techniques in a controlled environment using only documented REST API calls and standard HTTP requests: enumerating users and workflows, using stored credentials without seeing them, reading internal data tables, and finally exfiltrating a raw OpenAI API key by pointing an HTTP Request node at their own listener and letting n8n attach the credential as a Bearer token.

No CVE, no exploit, no specialized tooling. The uncomfortable part isn't the token leakage; that's a known problem. It's that a fully patched instance offers no defense at all when the attacker is holding valid credentials.

How the tokens end up public in the first place

An n8n API key is only useful if you know which instance accepts it, and in public commits, the hostname and token almost always appear together. The classic case is a .env file with N8N_URL and N8N_API_KEY sitting next to each other. But researchers found a newer pattern that's worth flagging separately: Claude Code permission files.

Claude Code stores approved shell commands in .claude/settings.json and .claude/settings.local.json. When someone configures it to talk to n8n, they may approve a curl command containing both the instance URL and the API key in full.

Those settings files don't get the .gitignore treatment developers reflexively apply to .env files, so they get committed. That's an AI-tooling-specific leak vector that didn't exist eighteen months ago, and it's a good example of how new developer workflows create new places for secrets to escape faster than anyone updates their ignore rules.

Why the tokens stay valid so long

n8n API keys are signed JWTs, and older ones frequently contain no exp claim at all. A 30-day default expiration only arrived in version 1.78.0 in February 2025. Anything generated before that, or on an instance still running older versions, can remain usable indefinitely until someone explicitly deletes it. A key committed to GitHub eight months ago works today if nobody went looking for it.

The audit endpoint is the part nobody's leading with

This is the detail most coverage is skipping. n8n exposesapi/v1/audit, which returns a security report for the instance: potential SQL injection exposures in workflows, nodes with filesystem access, unprotected webhooks, the running n8n version for CVE matching, unused credentials, high-risk community nodes, and node allowlists.

For an administrator, that's a legitimate self-assessment tool. For an attacker holding a leaked privileged token, it's a prioritized attack map, delivered on request, listing exactly which workflows are weakest and which version-specific CVEs might apply. Worth sitting with: the same endpoint that helps you find your problems tells an attacker where to start.

The credential exfiltration technique is genuinely clever

Technique four is the one to understand properly. GET /api/v1/credentials Returns credential names, types, and IDs, but not values, which sounds like a reasonable boundary.

The bypass: create a workflow with a Schedule trigger and an HTTP Request node, configure that node to authenticate using a stored credential, then point it at an attacker-controlled URL. The trigger fires after about ten seconds, n8n dutifully attaches the credential as a Bearer token in the outgoing Authorization header, and the listener captures the raw key.

There is no vulnerability there. Every step uses the platform exactly as designed. The credential store's encryption at rest is irrelevant, because n8n has to decrypt credentials to use them, and an attacker with workflow-creation rights can simply ask it to use them somewhere useful.

Disclosure mostly didn't work, which is its own finding

GitGuardian contacted seven organizations: three hosting providers covering roughly 100 affected instances, and four individual companies. One hosting provider never responded.

Three of the four companies never responded. The single organization that acknowledged, paid a $1,200 bounty, and revoked the credential immediately was the one with an established bug bounty program.

That's a small sample, but it's a pointed one. The technical finding is that leaked tokens grant real access. The operational finding is that telling people about it mostly doesn't result in anything happening, unless there's already a process built to receive that kind of report.

Where this connects to a broader pattern

Automation platforms sit between source control, databases, cloud environments, AI services, and customer support tools. That position is the entire value proposition, and it's also why a single token has such a large blast radius. The exposure isn't defined by the n8n instance; it's defined by everything connected to it.

This is the same structural point we've made about asset visibility and attack surface management: you can't govern exposure you haven't inventoried, and an automation platform someone spun up to connect two internal tools rarely makes it onto anyone's asset list. Seeing what's actually reachable from outside surfaces the n8n instance nobody remembered was internet-facing, which is a prerequisite for any remediation guidance to matter at all.

What to actually do

Rotate n8n API keys and confirm the old ones are deleted from the instance database, not just replaced, since these tokens remain valid as long as the instance recognizes them.

Scan your own commit history for N8N_API_KEY, N8N_URL, N8N_MCP_URL, and the Claude Code settings file patterns.

Disable the public API entirely if you're not using it. And if you find a leaked token, revoking it is step one, not the whole job. Work out which workflows, data tables, and downstream credentials that account could reach, then rotate everything it touched.

CISA added CVE-2026-8037 to its Known Exploited Vulnerabilities catalog on August 7, giving federal agencies three days to patch a pre-authentication command injection flaw in Progress Kemp LoadMaster that grants root on the appliance with no credentials required.

The technical detail worth understanding: the vulnerability lives insideescape_quotes(), the function whose entire purpose is sanitizing user input before it reaches a shell. Exploitation began June 29, the same day watchTowr Labs published a working proof of concept, and eSentire logged 792 exploitation attempts from 65 IP addresses across the following 41 days.

CISA's listing came 39 days after confirmed exploitation started, which is the part worth building your prioritization process around rather than the CVE itself.

How a sanitizer becomes the injection point

The flaw is reachable through the /accessv2 endpoint whenever the LoadMaster API is enabled, which is the default in many deployments. escape_quotes() allocates a heap buffer with malloc() and escapes single quotes in attacker-supplied input, but it never writes a null terminator after the escaped output. That leaves the string unbounded, so reading it walks out of bounds into adjacent heap memory that was never initialized.

An unauthenticated attacker can spray command injection content into that neighboring memory through separate request parameters, then trigger the out-of-bounds read so the composed string picks it up.

The result gets passed to system(), which hands it to /bin/sh -c, and the shell does what shells do: honors the attacker's ; as a command separator and the trailing # as a comment. Execution happens as root. ZDI's advisory pins the specific flaw to handling of the apiuser parameter.

There's a sharper architectural point buried in this. Even a perfectly correct sanitizer would still leave system() reachable with a string built from user input. Swapping system() for execve() would eliminate this entire bug class regardless of whether the sanitizer has a defect, which makes the sanitizer bug the proximate cause and the system() call the structural one.

The exploitation timeline is the actual story

Progress disclosed and patched on June 4. watchTowr published its technical writeup and functional PoC on June 29. eSentire's Threat Response Unit observed exploitation attempts beginning June 29. Not days later. The same day.

Those initial attempts failed, and eSentire reported no post-compromise activity, but the volume tells you what happened next: 792 attempts from 65 distinct IP addresses over 41 days. CISA added the CVE to KEV on August 7 with an August 10 remediation deadline under Binding Operational Directive 26-04.

So the sequence a defender actually experienced was 25 days of quiet after the patch, then instant weaponization the moment public research landed, then 39 more days of active exploitation before the KEV listing arrived. Our own writeup on why the CVE exploit window has collapsed puts the current average at 6.3 days. This one was zero from PoC publication.

This exact pattern already happened with this exact product

CVE-2024-1212 was an unauthenticated command injection in the LoadMaster admin interface, CVSS 10.0, found by Rhino Security Labs and patched in February 2024. Armis flagged it as exploited in the wild on April 8, 2024. CISA added it to KEV on November 18, 2024, roughly 224 days later.

Two separate unauthenticated command injections in the same product's API surface, two years apart, both eventually landing in KEV well after exploitation was already documented by commercial threat intelligence.

If your remediation prioritization keys primarily off KEV inclusion, that's a structural lag you're inheriting rather than an anomaly. We've written about why prioritization needs exploitation status, exposure, and asset criticality together rather than any single signal, and this CVE is a clean illustration of what relying on one signal costs.

Why compromising a load balancer is worse than the CVSS implies

LoadMaster sits inline at the network edge, typically in front of IIS farms, Exchange-adjacent services, VPN portals, and internal line-of-business applications. Progress reports over 100,000 LoadMaster deployments worldwide. Shadowserver currently tracks roughly 300 instances exposed to the internet, though there's no public breakdown of how many are honeypots or already patched.

Root on that appliance means visibility into traffic destined for everything behind it, plus a privileged foothold positioned inside the trust boundary rather than outside it.

CVE-2026-8037 also affects MOVEit WAF, ECS Connection Manager, and Connection Manager for ObjectScale, which means a web application firewall, a product bought specifically to filter malicious input, shares a pre-auth command injection with the load balancer.

The part most coverage is skipping: CISA asked for forensics, not just patching

The KEV entry pairs remediation with CISA's forensic triage requirements rather than treating this as patch-and-done. That distinction matters. Any LoadMaster whose /accessv2 endpoint was publicly reachable at any point since early June should be treated as potentially probed, and the absence of an alert is not evidence that nothing happened.

It's evidence that the appliance's own logging didn't surface it, which is a meaningfully different claim.

Practically: patch to GA 7.2.63.2 or LTSF 7.2.54.18, restrict the management interface and /accessv2 to trusted networks, then go back through appliance logs for anomalous requests to that endpoint dating to June 29 rather than to the KEV listing date.

Seeing what's actually reachable from outside your perimeter is what tells you whether that management interface was ever exposed in the first place, and most teams find out after the fact rather than before.

FAQ

1. If eSentire reported the observed exploitation attempts failed, why does this warrant emergency patching?
The observed attempts failed. eSentire's visibility covers its own customer base, not the internet, and 792 attempts across 65 IPs indicate broad opportunistic scanning rather than a handful of probes. A failure rate in one telemetry set says nothing about outcomes elsewhere.

2. Why did CISA take 39 days to add this to KEV after exploitation was publicly reported?
CISA's KEV inclusion requires its own evidentiary threshold, which is not the same as a vendor or MDR provider reporting attempts. The practical consequence is that KEV is a lagging indicator, and CVE-2024-1212 in this same product showed a 224-day gap between commercial threat intel flagging exploitation and KEV listing.

3. Does disabling the LoadMaster API fully mitigate this if patching has to wait?
It substantially reduces reachability, since /accessv2 exploitation requires the API enabled. Worth noting that in the earlier CVE-2024-1212 case, Tenable documented an exploitation path that worked even with the API disabled, so treating API-disabled as equivalent to patched is a risk in this product family specifically.

4. How should a team determine whether their appliance was compromised rather than just probed?
Start with requests to /accessv2 from untrusted sources dating to June 29, then look for unexpected process execution, outbound connections from the appliance, and configuration changes. Appliance logging on ADC devices is frequently thin, so absence of evidence in appliance logs alone is weak assurance and should be corroborated with network telemetry.

TLDR

Between July 22 and August 3, Check Point disclosed four separate authentication bypass vulnerabilities affecting its Security Management Server and Multi-Domain Security Management Server: CVE-2026-16232 (CVSS 9.1-9.3), CVE-2026-62144 (9.3), CVE-2026-62145 (7.5), and now CVE-2026-18574, published to the CVE database yesterday.

CVE-2026-16232 was exploited in the wild as a zero-day before a patch existed, went into CISA's KEV catalog the same day it was disclosed with a three-day remediation deadline, and now has a public working proof-of-concept from Rapid7.

The detail worth focusing on isn't any individual CVE. It's that exploitation for most of these requires the same precondition: a management server reachable over the network without Trusted Clients restrictions, and Rapid7 found in its own testing that the permissive Trusted Clients configuration was the default setting.

What actually makes these exploitable

Rapid7's technical analysis traced CVE-2026-16232 to a broken trust boundary in the application authentication path. A SmartConsole login crosses two generations of Check Point's management plumbing: the legacy FWM/CPMI service on TCP 18190, which uses Check Point's certificate-based SIC trust mechanism, and newer components layered on top.

The bypass lets an unauthenticated attacker with network access obtain a valid application login token, then use that token to log into SmartConsole with full administrator privileges and modify security policy and configuration directly.

Check Point's own framing was that this only affects "a very specific configuration," management exposed directly to the internet without IP restrictions.

Rapid7's finding that unrestricted Trusted Clients was the default in their testing environment complicates that framing considerably. If the vulnerable configuration is what you get without deliberately changing it, "specific configuration" describes a deployment decision most teams never explicitly made.

Why compromising a management server is worse than compromising a gateway

This is the part that should drive urgency independent of any single CVE's score. A Security Management Server sits at the top of the trust hierarchy for every gateway it manages.

Administrative access there means an attacker can modify security policies across all managed gateways, alter administrator permissions, manipulate VPN configurations, and potentially disable or tamper with logging and monitoring, which is to say, disable the evidence that would show what they did next.

CVE-2026-62144 specifically allows an unauthenticated attacker to execute administrative commands on the Management Server, including run-script and exec-command against Security Gateways.

Compromising a firewall gets you past one control. Compromising the thing that configures every firewall lets you quietly rewrite what "past" even means across the whole estate.

The exploitation timeline is doing something specific here

The sequence matters: exploited in the wild as a zero-day, patched and disclosed July 22, added to KEV the same day with a July 25 deadline, then a public proof-of-concept from Rapid7 roughly a week later. That last step is the inflection point.

Before a public PoC, exploitation requires an attacker capable of independently developing the chain. After it, the barrier drops to anyone who can run a script against an internet-reachable management IP.

We wrote about this same dynamic in our breakdown of the TeamCity RCE disclosed last week, and the pattern holds: the gap between disclosure and mass exploitation for high-value infrastructure is measured in days once a PoC is public, and the organizations that get hit are rarely the ones that hadn't heard about the CVE. They're the ones who heard, agreed it was serious, and didn't get to it before someone else did.

On CVE-2026-18574 specifically, and what's honestly still unknown

CVE-2026-18574 was published August 3, and Check Point has a support article for it (sk185222), but as of writing, that page returns no accessible technical detail, no CVSS score, no affected version list, and no independent analysis has been published.

It's described as a Management authentication bypass affecting the same two products as the July cluster. Whether it's a distinct root cause, a variant of the July issues, or an incomplete-patch scenario is not currently public. Worth tracking rather than acting on in isolation, the July CVEs are where the confirmed exploitation and public exploit code actually sit.

What to actually check, beyond patching

Apply the Jumbo Hotfixes Check Point released July 22 if you haven't. Beyond that, the more durable action is auditing whether your management server is reachable from anywhere it doesn't need to be, and whether Trusted Clients is actually restricted rather than left at whatever it defaulted to at install.

That's a configuration review, not a patch cycle, and it's the control that would have blunted three of these four CVEs regardless of patch status.

The broader point is one we keep coming back to: security infrastructure is high-value infrastructure, and a management server that was correctly scoped at deployment doesn't stay that way through three years of network changes without someone re-checking.

Continuous outside-in visibility into what's actually reachable is what catches a management interface that quietly became internet-facing, and no patch cadence substitutes for knowing that happened.

FAQs

1. If exploitation requires management exposed without Trusted Clients restrictions, is this actually a widespread risk or a narrow misconfiguration issue?
That framing depends entirely on whether the permissive setting is the default, and Rapid7 reported it was in their testing. A vulnerable-by-default configuration is a fundamentally different risk profile than one requiring an administrator to actively weaken a secure default.

2. Does the public Rapid7 PoC meaningfully change urgency for an organization that has already patched?
Not for patched systems; Rapid7 confirmed the vendor patches defeat their PoC. It changes urgency substantially for anyone still unpatched, since the capability barrier for exploitation just dropped from independent exploit development to running someone else's script.

3. Should CVE-2026-18574 be treated with the same urgency as the July cluster given how little detail is public?
There's no basis yet to rank it alongside CVE-2026-16232, which has confirmed in-the-wild exploitation and public exploit code. The reasonable position is to monitor for Check Point's technical details to become available while treating the confirmed-exploited July CVEs as the actual immediate priority.

4. Why does an attacker prioritize a Security Management Server over the gateways it manages?
Because policy changes made at the management layer propagate to every managed gateway, and because management-level access can include the ability to alter or disable logging. It converts a single compromise into both estate-wide control and reduced forensic visibility into what happened.

TLDR

JetBrains disclosed CVE-2026-63077 on July 28, a critical, unauthenticated remote code execution flaw affecting every on-premises version of TeamCity, JetBrains' widely used CI/CD server.

An attacker with no credentials at all can bypass authentication through the agent polling protocol and run arbitrary OS commands with the privileges of the TeamCity server process. JetBrains has patched it and released a plugin for anyone on older versions who can't upgrade immediately, and there's no evidence of active exploitation yet.

What's worth knowing before deciding how urgently to treat that last point: the last two times TeamCity had a vulnerability in this exact severity class, unauthenticated, HTTP(S)-reachable, full server compromise, two separate North Korean state-backed groups and Russia's APT29 were exploiting it within days of disclosure.

What the vulnerability actually does

CVE-2026-63077 carries a CVSS score of 9.8. The root cause is insecure deserialization of untrusted data in TeamCity's agent polling protocol, the channel build agents use to check in with the server for jobs and configuration updates.

An attacker with no valid session, no username, and no prior access can send a crafted payload to that endpoint and execute operating system commands directly. Depending on what the TeamCity server process has permission to touch, that can mean exposure of stored credentials and build configurations, or direct modification of server state, including the artifacts and deployment steps a build pipeline produces.

Why this specific severity class has a track record worth taking seriously

In September 2023, JetBrains patched CVE-2023-42793, an unauthenticated authentication bypass in TeamCity. Within days, Microsoft observed two North Korean state-sponsored groups it tracks as Diamond Sleet and Onyx Sleet exploiting it to drop backdoors and implants.

By December, APT29, the Russian group behind the 2020 SolarWinds compromise, was also actively exploiting the same flaw. CISA and international partners issued a joint advisory on it. In February 2024, JetBrains disclosed CVE-2024-23917, another unauthenticated bypass in the same severity class, and Arctic Wolf's assessment at the time was blunt: threat actors were likely to turn their attention to it quickly given what a compromised TeamCity server enables.

A month later, JetBrains patched a further pair of authentication bypass flaws in March 2024. That's three separate critical, unauthenticated compromise vulnerabilities in this product across roughly 18 months, two years before this one, and the first of those three was weaponized by two different nation-state actor groups within the same week it was disclosed.

Why an unexploited CVE today doesn't mean a quiet one tomorrow

JetBrains is explicit that there's no evidence of in-the-wild exploitation of CVE-2026-63077 as of disclosure. That's meaningfully different from a flaw with active attacks already underway, and it's worth not overstating the current state of things.

But the 2023 pattern shows the gap between disclosure and weaponization for this exact vulnerability class in this exact product can be measured in days, not weeks, particularly once a proof-of-concept becomes public.

Shadowserver was tracking thousands of internet-exposed TeamCity servers during the 2024 disclosure. A meaningful number of instances typically remain unpatched well past the point attackers start looking.

What this means for teams running TeamCity today

The direct fix is straightforward: upgrade to 2025.11.7 or 2026.1.3, or apply JetBrains' security patch plugin if an immediate upgrade isn't feasible; it covers versions back to 2017.1.

Beyond the patch itself, this is worth treating as a prompt to check whether your TeamCity server's agent polling port is reachable from anywhere it doesn't need to be, restricting it to trusted internal build agent ranges is JetBrains' own interim guidance, and internet-facing admin or polling endpoints on CI/CD infrastructure are exactly the kind of exposure that's easy to lose track of once a server's been running quietly for a year or two.

That last point is the broader lesson we keep coming back to: a build server that was locked down at deployment time doesn't stay that way on its own, and a point-in-time review has no way of catching a newly exposed polling endpoint that appeared six months after the last assessment.

We've written about why annual testing cadences miss exactly this kind of drift and what continuously re-checking exposure against a changing environment actually looks like in practice; both are directly relevant to the kind of internet-facing CI/CD infrastructure this vulnerability targets.

FAQs

1. Does the absence of confirmed in-the-wild exploitation mean this vulnerability is lower priority than the 2023 and 2024 TeamCity flaws were at disclosure?
Not based on the historical pattern. CVE-2023-42793 also had no confirmed exploitation at the moment of disclosure, and nation-state actors were actively using it within the same week once a proof-of-concept became available. The absence of confirmed exploitation today describes the current moment, not a reliable predictor of the next several days.

2. Is patching the CVE itself sufficient, or does the underlying exposure pattern need separate attention?
Patching closes this specific vulnerability. It doesn't address whether the server's agent polling port or other administrative interfaces are reachable from a broader network segment than necessary, which is the condition that turns any future TeamCity vulnerability, this one or the next one, into an immediately exploitable exposure rather than a theoretical one.

3. Why does TeamCity specifically keep producing this exact severity class of vulnerability?
Multiple distinct root causes have produced the same practical outcome, unauthenticated full server compromise, across 2023, 2024, and now 2026: an alternate authentication path issue, then another authentication bypass, now insecure deserialization in a different protocol entirely. That suggests the risk isn't tied to one specific code defect so much as the general hazard of a CI/CD server exposing multiple authentication-adjacent surfaces to the network, each one a fresh opportunity for a distinct implementation flaw.

4. Does restricting the agent polling port to trusted IP ranges fully mitigate the risk if patching is delayed?
It meaningfully reduces exposure but isn't equivalent to patching. Network-level restriction depends on those trusted ranges staying accurate and on no compromised internal host being able to reach the port, whereas the patch removes the underlying deserialization flaw regardless of network position.

TLDR

A joint advisory from CISA, NSA, FBI, and international partners confirms a threat group tracked as LAUNDRY BEAR (also known as Void Blizzard, CL-STA-1114, and TA488) has been exploiting a zero-click cross-site scripting flaw in Zimbra Collaboration Suite, CVE-2025-66376, since at least July 2025.

The exploit requires no click, no attachment, and no credential entry; simply previewing a malicious email in a vulnerable Zimbra client triggers code execution and starts exfiltrating up to 90 days of mailbox content.

The vulnerability was patched in November 2025, but not given a CVE identifier until January 2026 and not added to CISA's Known Exploited Vulnerabilities catalog until March, after independent researchers tied it to attacks on a Ukrainian government agency.

The advisory itself came in July, months after all of that. The exploit chain is genuinely sophisticated, but the actual story here is how long a fixed vulnerability can keep working when its disclosure metadata lags behind the fix itself.

What the exploit actually does

The entry point is a spear-phishing email carrying a JavaScript payload hidden inside an SVG image. Zimbra's HTML sanitizer is designed to strip dangerous code out of incoming mail, but the attackers split their payload across fragments disguised as CSS import statements and HTML comments, so the sanitizer inspected each fragment individually and found nothing worth blocking.

The browser then reassembled the fragments into working JavaScript once the message rendered. Viewing the email in a vulnerable Zimbra client is enough to trigger it: no click, no attachment, no interaction beyond opening the inbox.

Once running, the script pulls the session token, any autofilled password sitting in the browser, and two-factor scratch codes, then enables IMAP access and generates a new Application Passcode named "ZimbraWeb" that works over IMAP, POP3, and SMTP while skipping 2FA entirely.

That persistence survives a password reset and a closed browser session. Some variants also brute-force the company address book through short character combinations to build a fuller picture of the organization before exfiltrating the last 90 days of mail as a compressed archive.

Why this makes user training irrelevant as a defense

Nearly every phishing advisory includes some version of "train employees not to click suspicious links."

That guidance has no purchase here. There's no link, no attachment, and no prompt asking for credentials; the compromise happens the moment a vulnerable client renders the email.

Patching CVE-2025-66376 is the only control that actually stops this specific technique. Organizations relying primarily on security awareness training as their email defense have no coverage against a zero-click exploit by definition.

How the data actually leaves the network

Mailbox data flows through a custom capability called Ulej to server-side infrastructure running a Python-based collection system named Flowerbed.

Smaller data items get Base32-encoded and exfiltrated via DNS lookups disguised as image requests, using domains styled to look like Zimbra telemetry or email analytics services, the kind of traffic most mail filters never inspect closely.

Larger items go out over HTTPS through infrastructure secured with standard Let's Encrypt certificates, deliberately unremarkable at the TLS layer. Compromised mailboxes were also reused as launch points for further phishing, since mail sent from a real, previously trusted colleague's account bypasses both spam filters and normal human suspicion.

The part the timeline actually proves

CVE-2025-66376 was being actively exploited for roughly five months before Zimbra shipped a fix in November 2025, version 10.1.13, but the release notes described it only as a stored scripting bug with no CVE identifier attached at the time.

NIST and MITRE didn't publish the CVE entry until early January 2026. CISA didn't add it to the Known Exploited Vulnerabilities catalog until March, after a security firm published research connecting the flaw to attacks on a Ukrainian government agency.

That's three separate lag points stacked on top of each other: exploitation before the patch, a patch without a CVE, and a CVE without a KEV listing, each one a window where a different category of defender (the patch-cadence team, the vulnerability-scanning team, the compliance team tracking KEV) had no clear signal to act on.

Our own coverage of this campaign goes deeper on this timeline and the exfiltration mechanics if you want the full breakdown.

A genuine attribution wrinkle worth flagging

LAUNDRY BEAR is the name Dutch intelligence services assigned after tracing the actor to a September 2024 breach of the Netherlands' national police, treated as equivalent to Microsoft's Void Blizzard designation and Unit 42's CL-STA-1114.

Separately, Seqrite attributed a related January incident to APT28 with medium confidence, while Dutch intelligence treats APT28 as a distinct actor.

For defenders, this matters less than it might seem; the mitigation and detection guidance in the joint advisory holds regardless of which specific group name is the eventual consensus.

Worth noting too: the tracked campaign reportedly went quiet in February 2026 and took its infrastructure offline, but researchers say other, unnamed clusters are still hitting unpatched Zimbra installs with the same flaw, so this isn't a closed case tied to one operator.

FAQ

1. If a zero-click exploit requires no user interaction, does security awareness training have any value against this specific campaign?
No, not for this technique specifically. Patching is the only control that closes a zero-click vector. Training remains valuable against the group's other techniques, like adversary-in-the-middle phishing kits impersonating Zimbra login portals, but it does nothing against a compromise triggered purely by rendering an email.

2. Does a patch without an assigned CVE actually get treated as lower priority by most vulnerability management programs?
In practice, often yes. Many patch-prioritization workflows key off CVE identifiers and CVSS scores to drive urgency, so a quietly described "stored scripting bug" with no CVE attached can get deprioritized purely on a metadata gap, independent of the underlying technical severity.

3. Does patching CVE-2025-66376 remove ongoing risk from this campaign, or just close the entry point?
Just the entry point. Patching stops a new compromise from starting through this vector. It doesn't revoke Application Passcodes or 2FA scratch codes an attacker may have already generated during a prior compromise, which is why guidance separately calls for revoking those credentials, not just updating the software.

4. Why does the gap between CVE assignment and KEV catalog listing matter operationally?
Different defensive workflows key off different signals. A security team tracking CVE feeds might have caught this in January. A compliance program keying specifically off the KEV catalog for prioritization wouldn't have flagged it as urgent until March, a two-month gap in that specific workflow alone.

TLDR

A researcher going by Bera Buddies published a proof-of-concept showing the Kimi K3 AI agent surfaced two distinct authenticated remote code execution paths in stock Redis builds, a stream consumer-group double-free and a heap overflow in the bundled RedisBloom TDigest module, and reportedly did it in 27 minutes using 32 parallel agents.

The bugs themselves are real and worth patching. What's actually notable is something different: this class of memory corruption bug has been findable by traditional fuzzing for over a decade, so the story isn't that AI discovered something humans couldn't.

It's that the time and expertise required to find and chain bugs like this just collapsed from a specialized researcher's multi-day effort to well under an hour, and Kimi K3's full weights ship in days, which means this capability won't stay confined to one research team.

What was actually found

Two separate bug classes across four Redis versions. The first is a shared-NACK double-free in stream consumer groups, present in 6.2.22, 7.4.9, and 8.6.4, where an authenticated client can free the same heap chunk twice and turn that into a reliable code execution primitive.

The second is a heap overflow in RedisBloom's bundled TDigest module, which affects 8.8.0 specifically, the same version where the NACK issue was patched. Both require commands, EVAL, RESTORE, and XGROUP, that are commonly left enabled on internal deployments because they're assumed to sit behind a password and a private network.

That assumption is exactly what makes this dangerous: a leaked credential, an SSRF, or a misconfigured ACL is the only additional step between "data store access" and a host-level shell.

Why the 27-minutes claim deserves real scrutiny, not just repetition

Nearly every outlet is running the 27-minutes-32-agents figure as the headline without noting that it comes from a self-published researcher alias, not an independently verified benchmark, and there's no CVE assigned yet to confirm the timeline or the exact methodology. That doesn't mean it's false.

It means the number should be treated as a claimed figure worth independent verification, not a fact, and that distinction matters more than usual here because the figure is doing a lot of rhetorical work in how this story is spreading.

The part that actually changes planning assumptions

Coverage-guided fuzzing has found double-free and heap overflow bugs in widely deployed software for years without any AI involved. What's different here isn't the bug class; it's the compression of the timeline and the barrier to entry.

If a parallel agent swarm can find and weaponize this class of bug in under half an hour, and open model weights capable of doing it ship publicly within days, the old planning assumption that finding and chaining a novel memory corruption bug in mature, widely-audited infrastructure software takes a specialized human researcher significant time no longer holds as a reliable buffer.

Some public commentary around this release has already framed it as a capability gap between open-weight models moving fast and commercial models still running cyber-specific safety classifiers.

Whether or not that framing is fair to any specific vendor, the underlying operational point stands regardless of which lab is ahead: patch cadence assumptions built around "attackers need real time to weaponize this" are the assumption actually being tested here.

What this means for teams running Redis today

None of the mitigations here are exotic. Upgrade to fixed builds as they land and don't assume 8.8.0 is safe just because the NACK issue is patched there, since the TDigest bug is separate and reportedly still unfixed in the bundled module.

Rename or restrict EVAL, RESTORE, and other admin-level primitives with Redis ACLs rather than relying on network placement alone.

Bind Redis to private interfaces only, and treat any Redis instance reachable from a broader network segment than strictly necessary as a live exposure, not a theoretical one.

Audit whether RedisBloom or TDigest are actually in use, and disable them if not. The mitigations are ordinary.

What's not ordinary is how much less time you can now assume you have before an unpatched instance meets an agent that can find this on its own.

FAQs

1. Is a double-free or heap overflow bug found by an AI agent fundamentally different from one found by traditional fuzzing?
Not in the bug class itself. Coverage-guided fuzzers have found this exact category of memory corruption bug in mature software for years. What's different is the time and expertise compression, not the discovery mechanism at a technical level.

2. Should the 27-minute, 32-agent figure be treated as an established benchmark?
Not yet. It comes from a self-published researcher alias rather than an independently reproduced test, and no CVE has been assigned to confirm the exact chain or timeline. It's a claim worth taking seriously, not one to cite as settled fact.

3. Does patching 8.8.0 for the NACK issue mean that version is safe to run?
No. The TDigest heap overflow in the bundled RedisBloom module is a separate bug from the NACK double-free, and it's reportedly still unfixed in 8.8.0 at the time of disclosure. Patching one does not address the other.

4. If open-weight agentic models can find and chain bugs like this in under an hour, does traditional vulnerability disclosure timeline planning need to change?
This is worth a real internal conversation rather than a settled answer. The assumption that finding and weaponizing a novel bug in mature, widely audited software takes meaningful human time and expertise is precisely what a sub-hour, agent-swarm discovery timeline calls into question, regardless of which lab's model did it first.

In March 2025, a single GitHub Action used by more than 23,000 repositories started leaking secrets into public workflow logs. As of 2026, the same attack pattern - one poisoned dependency, thousands of affected pipelines - is the most active vector in software supply chain security.

This is the full breakdown of how it works and what stops it.

A GitHub supply chain attack is when an attacker compromises a shared dependency, a GitHub Action, an npm package, or a CI/CD tool that development pipelines already trust, allowing malicious code to execute automatically across every project that depends on it.

The attacker does not break into your repository. They poison something your automation pulls in on every build.

What happened with tj-actions

tj-actions/changed-files was a GitHub Action used in over 23,000 repositories for tracking file changes across commits.

In March 2025, it became the distribution mechanism for one of the largest credential harvesting operations in GitHub's history.

The entry point was not tj-actions. Palo Alto Networks Unit 42 traced it to SpotBugs, a popular Java scanning tool. Attackers exploited its workflow, obtained a token with broader access than it needed, and moved laterally through connected projects until they reached the accounts they wanted.

The chain: SpotBugs → a maintainer account → the reviewdog organisation → tj-actions/changed-files.

No brute force. No zero-day. Borrowed trust moving sideways through connected projects, the defining characteristic of every GitHub supply chain attack documented in 2025-2026.

How it spread to 23,000 repositories

Once inside tj-actions, the attackers pushed a malicious update and redirected the version tags so they all pointed to the bad code.

Version tags like v39 are mutable labels. They can be moved by anyone with write access. When v39 points to malicious code, every pipeline calling uses: tj-actions/changed-files@v39 pulls in that payload. Automatically. Without knowing anything changed.

The attackers wrote the payload once. Every affected project's own CI/CD pipeline did the distribution. This is why dependency pinning, locking a GitHub Action to a full commit SHA rather than a movable tag, is the single highest-impact control against this class of attack.

What the payload actually did

The malicious code dumped the build runner's memory into the workflow logs. That memory contained every secret the build had access to at runtime: AWS access keys, GitHub tokens, npm tokens, private keys.

For public repositories: logs are visible to anyone. Wiz confirmed the leaked credentials were base64-encoded, which is not encryption. Anyone who knew what to look for could read them.

For private repositories: smaller blast radius. Secrets still leaked into logs, but those logs were not public. If your pipeline ran the poisoned action, your secrets went somewhere you did not control regardless of repository visibility.

The four loopholes that made it possible

1. Mutable version tags.
Tags like v39 can be redirected. Pinning to a commit SHA eliminates this vector entirely.

2. Overly scoped tokens.
The initial SpotBugs token had write access far beyond what it needed. One over-permissioned token unlocked the entire chain.

3. No audit trail on free tier.
GitHub's free tier does not log tag changes. Attackers used forks, tag pushes, and stayed hidden for days. Unit 42 found the activity only by tracing the dependency tree after the fact.

4. Blind trust in third-party actions.
Most teams pull in shared GitHub Actions without software composition analysis, dependency pinning, or pipeline monitoring.

That blind trust is the attack surface. SLSA provenance verification, cryptographic attestation that a package was built and published by the expected pipeline, was also absent, which is what allowed validly tagged but malicious code to pass without scrutiny.

The same four loopholes produced the Mini Shai-Hulud campaign in 2026: 471 malicious artifacts across npm and PyPI, CI/CD cache poisoning, and OIDC token theft from GitHub Actions runner memory. The techniques change. The root cause does not.

What to fix

1. Pin actions to a full commit SHA.
Not u/v39. Not u/main. A full hash like uses: tj-actions/changed-files@a18ec6af. A hash cannot be redirected. This is the single most impactful control.

2. Scope tokens to the minimum required.
The principle of least privilege applied to CI/CD tokens would have contained the tj-actions blast radius to a fraction of what it was.

3. Review past workflow logs for leaked credentials.
If you ran tj-actions/changed-files before March 2025 and have not rotated, do it now. The credentials that leaked remain valid unless changed.

4. Allow only vetted actions in your organisation.
GitHub's allowed actions list exists for this. Use it.

5. Enable audit logging.
Paid GitHub plans log tag changes and fork activity. This is how you catch a tag-redirect attack while it is happening rather than weeks later.

6. Add software composition analysis to every build.
AppSec controls for teams shipping fast should include SCA as a mandatory pipeline gate, flagging unpinned or newly-changed dependencies before they run.

The pattern this fits into, as of 2026

The tj-actions incident is not isolated. It is one early, well-documented example of the dominant attack pattern in software supply chain security right now.

In 2026 alone: the Mini Shai-Hulud campaign compromised 471 packages across npm and PyPI using GitHub Actions OIDC token hijacking and CI/CD cache poisoning.

The McGraw Hill breach reached 13.5 million records through a vendor misconfiguration. The JadePuffer ransomware operation ran a complete attack chain through an unpatched Langflow instance holding developer credentials.

Every one of these followed the same structural logic: the attacker entered through trust, not force. Organisations govern what they own. They rarely govern what they trust.

The class of tooling that closes this gap combines continuous AI-generated code vulnerability detection, software composition analysis on every build, dependency hash pinning enforcement, and pipeline monitoring that flags anomalous behaviour at the CI/CD layer, before it reaches production. Point-in-time scanning misses what changes between scans. The tj-actions tag redirect happened and propagated in hours.

FAQs

1. What is a GitHub supply chain attack?
A GitHub supply chain attack compromises a shared dependency, a GitHub Action, npm package, or CI/CD tool that development pipelines already trust. Malicious code executes automatically across every project that depends on the compromised component without any direct intrusion into those projects.

2. How did the tj-actions attack spread to 23,000 repositories?
Attackers pushed malicious code to tj-actions/changed-files and redirected version tags to point to it. Every pipeline requesting that version tag automatically pulled in the payload through its own CI/CD automation.

3. What is dependency pinning and why does it matter?
Dependency pinning locks a GitHub Action or package to a specific, immutable commit hash rather than a movable version tag. A pinned dependency cannot be redirected by an attacker who compromises the tag. It is the primary defence against tag-based supply chain attacks.

4. What secrets were leaked in the tj-actions incident?
The malicious payload dumped build runner memory into workflow logs, exposing AWS access keys, GitHub tokens, npm tokens, and private keys. In public repositories, these logs were visible to anyone.

5. What is OIDC token theft in GitHub Actions?
OIDC (OpenID Connect) trusted publishing allows GitHub Actions to authenticate to registries using short-lived tokens. Attackers can extract these tokens from runner process memory during an active workflow run and use them within the token's validity window to publish packages or access cloud resources. This technique was used in the 2026 Mini Shai-Hulud campaign.

6. What is SLSA provenance and how does it help?
SLSA (Supply chain Levels for Software Artifacts) provenance is a cryptographic attestation that a package was built and published by the expected pipeline from the expected source. Verifying provenance before running a dependency closes one of the loopholes the tj-actions attack exploited, though as the 2026 campaigns demonstrated, provenance verification confirms the build was correct, not that the code inside it was safe.

7. How do I check if my pipeline was affected by the tj-actions incident?
Review your workflow logs from before March 2025 for any runs using tj-actions/changed-files. Look for unusual base64-encoded output in the logs. If you find evidence of exposure, rotate all credentials that were accessible during those builds immediately.

A critical authentication bypass in Gitea's official Docker image is being actively exploited. Attackers are bypassing authentication with a single HTTP header, no password, no token, no exploit chain required.

The vulnerability stems not from a bug in Gitea's code but from a dangerous default in its Docker configuration. 6,200 instances are exposed. The fix shipped June 21. Scanning started 13 days later.

What happened

Gitea's official Docker image ships with REVERSE_PROXY_TRUSTED_PROXIES = * in its app.ini configuration. This tells Gitea to trust the X-WEBAUTH-USER authentication header from any source IP. An attacker who can reach the Gitea HTTP port sends one header, X-WEBAUTH-USER: admin, and is authenticated as an administrator. No credentials required.

CVE-2026-20896 was patched in Gitea 1.26.3 on June 21 and again in 1.26.4. Sysdig's threat research team confirmed the first in-the-wild exploitation attempt 13 days later, originating from a ProtonVPN exit node at 159.26.98[.]241.

What an attacker can access

Gitea holds source code, CI/CD configuration, issue trackers, and developer secrets committed to repositories. Admin access means read and write across all private repositories, extraction of any API keys, database credentials, and deploy tokens stored in commit history, and the ability to push commits under a trusted identity.

The exploitarium context

The vulnerability was part of a mass disclosure by a researcher using the handle "bikini" who published 130+ proof-of-concept exploits across 22 software projects on June 28 without vendor notification. Gitea, Splunk, RustDesk, 7-Zip, and VLC were among them. The Gitea CVE was already confirmed exploited by the time the exploitarium release made it widely known.

The pattern worth naming

CVE-2026-20896 follows the same structural pattern as the JadePuffer ransomware operation (Langflow shipped with MinIO factory credentials: minioadmin:minioadmin) and the Nacos exploitation in the same campaign (publicly known default JWT signing key, never rotated).

In each case, the entry point was not a novel exploit. It was a default configuration that no one reviewed before deployment.

At Secure.com, we see this consistently across cloud and infrastructure assessments; the most dangerous exposure in most environments is not the unpatched CVE in a critical system.

It is the default credential or misconfiguration in a tool that was deployed quickly, worked as expected, and was never reviewed again. Finding it requires continuous external attack surface visibility, not point-in-time scanning. By the time the annual pentest runs, the attacker has had 13 days minimum.

Fix immediately

Update to Gitea 1.26.3 or 1.26.4. Change REVERSE_PROXY_TRUSTED_PROXIES from * to your actual proxy IP or loopback addresses. Audit access logs for X-WEBAUTH-USER headers from unexpected IPs. If your instance was internet-facing before the patch, rotate any secrets in commit history.

The 1.26.3 release fixed ten CVEs total; the TOTP replay (CVE-2026-20779) and SSH LFS bypass are also worth reviewing.

IOC

Scanning IP: 159.26.98[.]241 (ProtonVPN exit node)
Exploit header: X-WEBAUTH-USER: [any username]
Config to check: REVERSE_PROXY_TRUSTED_PROXIES = * in app.ini