erroneo.us Security Digest

Act now: PHP2Shell: Critical Unauthenticated RCE in PHP

erroneo.us Security Desk — Wed, 21 Oct 2026 00:00:00 -0700

Verdict: Act now. If PHP answers HTTP requests anywhere you run it, patch or apply a vendor fix today; this is pre-application, unauthenticated, and attack traffic started before the patch shipped.

Who must act: Anyone running PHP behind a web server (mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed), including WordPress, Drupal, Magento, Laravel and appliance or container images that bundle PHP.
Who can relax: Hosts where PHP is only used from the command line (scripts, cron, Composer) and never handles untrusted HTTP requests, and RHEL 7 or older, which Red Hat says ships unaffected PHP.

Inventory every PHP that serves HTTP: servers, containers, appliances, shared hosting.
Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's fixed package, then restart every PHP worker (php-fpm, Apache).
Rebuild and redeploy container images from refreshed php:* or distro base images; do not just restart old containers.
For PHP 7.4-8.1, use a vendor/LTS backport or the PHP team's source backport branches, or upgrade.
If you cannot patch today: set session.upload_progress.enabled=0, enforce memory_limit=-1, set fatal_error_backtraces=0 on 8.5, block multipart/form-data where unused, and keep WAF rules on; otherwise take the site offline.
Verify the version actually serving requests, not just the CLI binary.

What happened

On October 21, 2026, PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two engine bugs that "can allow unauthenticated remote code execution." CVE-2026-109618 ("RCE via OOM corruption") is a fault in out-of-memory handling: PHP bails out mid-initialization and request shutdown then trusts half-built state. CVE-2026-109619 ("RCE via stale global state") lets request state outlive its freed memory so the next request on the same worker uses it. Both are use-after-free class bugs, rated CVSS 4.0 9.2 by PHP. Red Hat scores it 8.1 on CVSS 3.1 and notes NVD's 9.8.

Wiz Research found the bugs, with Calif and OpenAI also credited as reporters. Wiz confirmed unauthenticated RCE against Drupal and WordPress in August. The triggering code dates to PHP 5.4 (2012), and a plain "Hello World" app is enough. Sansec lists demonstrated RCE against Magento, WordPress, Drupal, Joomla, MediaWiki, Nextcloud, phpMyAdmin, Laravel and Symfony.

Who is affected

PHP says every installation serving web requests is at risk, whether it runs mod_php, PHP-FPM, php-cgi, FrankenPHP or LiteSpeed. The advisories rank the exposure by SAPI:

Apache mod_php: most exposed. RCE is confirmed with default limits, and the trigger fires while the request body is parsed, before any application code runs.
PHP-FPM: one path is blunted because FPM kills a child whose startup fails. Session-lifecycle RCE was still validated against FPM.
FrankenPHP and LiteSpeed (LSAPI): source analysis says likely susceptible, but this has not been validated.

PHP 8.1 and older get no upstream release. PHP published source backports for 7.4, 8.0 and 8.1. Versions 5.4 through 7.3 have no fix.

Do you really need to act?

Yes, today, if PHP is reachable over HTTP. The attack needs no login and no plugin bug, because it lands in the engine before your code runs. Updating WordPress or your framework does nothing. Exploitation has started. Cloudflare saw attack traffic, including payloads mutated to evade its rules, after details leaked ahead of the release. watchTowr reports exploitation attempts, according to Tenable. Exploits are build-specific (the CVSS vector says "high complexity"), but public tooling closes that gap quickly. These CVEs were not in CISA KEV at the time of writing.

Distro PHP (Debian/Ubuntu/RHEL): watch for backported fixes that keep the old version string. Debian fixed trixie (8.4.27-1~deb13u1, DSA-6574-1) and bookworm (8.2.35-1~deb12u1, DLA-4848-1). Ubuntu fixed 24.04 (php8.3 8.3.6-0ubuntu0.24.04.13) and 22.04 (php8.1 8.1.2-1ubuntu2.28), with 20.04 and older through Ubuntu Pro. Red Hat lists RHEL 8, 9 and 10 as affected with updates rolling out, and RHEL 7 as unaffected. Sansec warns that the Remi repository had not shipped fixes on day one.
Containers: the official php images were rebuilt on October 21. Pull, rebuild and redeploy. Restarting an old image does not patch it.
Managed WordPress and shared hosting: the host owns PHP. Confirm with them in writing. Self-managed VPS installs are on you.
CLI-only PHP (cron, Composer, CI) is not on the documented attack path. Patch it on your normal cycle.
Behind Cloudflare: WAF rules help, but only for traffic that actually passes through Cloudflare. They are not a fix.

What to do now

Inventory every PHP install that answers HTTP, including ones bundled inside appliances. The UK NCSC stresses this step.
Upgrade to a fixed release or your vendor's package (apt-get install --only-upgrade 'php8.*', dnf update 'php*'), then restart all workers: systemctl restart php8.3-fpm apache2.
Verify from the web side, not the shell. php -v reports the CLI binary. Check dpkg -l 'php*' or rpm -qa 'php*', and confirm the version a live request reports.
If you can't patch yet, apply PHP's temporary mitigations administratively and restart: session.upload_progress.enabled=0, enforced memory_limit=-1 (watch RAM), and fatal_error_backtraces=0 on 8.5. Block multipart/form-data where you don't use it. PHP says none of these is a complete fix, so failing that, take the site offline as Qualys and NCSC suggest.
Do not use RLIMIT_AS/RLIMIT_DATA as a mitigation. PHP warns they can trigger the vulnerable path.

How to tell if you were hit

Wiz notes that application logs may show little, because the bugs run below the app layer. Look for multipart POSTs carrying the upload-progress field followed by 500s or memory-limit errors, unusual PHP worker churn, and oversized or malformed PHPSESSID cookies. Any internet-facing host that was unpatched after October 20 deserves a hunt: new .php files in web roots, web shells, and unexpected shells or network tools spawned by php-fpm or httpd. Rotate the secrets those workers could read, because the bugs also leak process memory.

Timeline

Aug 11, 2026 — Calif reports a first bug to PHP (per Sansec).
Aug 24, 2026 — Wiz reports its findings to PHP.
Oct 20, 2026 — CVE IDs leak around 15:00 UTC, and a researcher's exploit video is briefly posted. PHP moves the release up from Oct 22 to Oct 21, 14:00 UTC (Socket).
Oct 21, 2026 — Cloudflare rules go live at 03:02 UTC. Chainguard ships patched images at 07:41 UTC, which the PHP Foundation calls an embargo break. Fixed releases, the GHSAs and the Wiz write-up are published at 14:00 UTC. Debian and Ubuntu ship fixes, and the official Docker images are rebuilt.

Sources

Patch this week: Node.js October 2026 Security Releases: 10 CVEs Fixed

erroneo.us Security Desk — Wed, 21 Oct 2026 00:00:00 -0700

Verdict: Patch this week. Four high-severity fixes, including a Brotli decoder memory-corruption bug the project says permits remote code execution, make this a routine-but-real upgrade: roll every supported line forward this week.

Who must act: Anyone running Node.js 22.x, 24.x or 26.x in production, especially services that decompress untrusted Brotli data or make TLS connections to hosts given as IP addresses.
Who can relax: Nobody needs to drop everything today: no exploitation is reported, and the low-severity Permission Model and ZIP fixes only matter if you use those features.

Check every runtime that serves traffic: node -v in each container, VM and CI image.
Upgrade to 26.12.1, 24.22.1 or 22.23.4 (nvm install 24.22.1, or your package manager / official node:* images), then restart processes.
Rebuild and redeploy container images and single executable applications (SEAs) so they embed the fixed runtime.
Move anything still on an End-of-Life line (20.x or older) to a supported LTS; EOL lines are always affected.
Rebuild startup snapshots and SEAs that use crypto.randomUUID() or crypto.randomInt(), so each process gets fresh entropy.

What happened

On October 21, 2026 the Node.js project shipped security releases for every supported line: 26.12.1 (Current), 24.22.1 (LTS) and 22.23.4 (LTS). The releases fix ten CVEs. Four are rated high, three medium and three low. They also pull in dependency updates for c-ares, OpenSSL, SQLite and Undici, plus a root-certificate change after the compromise of an eMudhra intermediate CA.

The four high-severity issues:

CVE-2026-111497: an out-of-bounds write in the bundled Brotli decoder. The project's own title says it "permits remote code execution". The fix is a cherry-picked upstream Brotli patch. It affects 26.x, 24.x and 22.x.
CVE-2026-106069: a TLS certificate hostname check bypass when the host loosely resolves to an IP address. It affects 26.x, 24.x and 22.x and is fixed together with the medium-rated CVE-2026-106072, under which DNS names in a certificate could authenticate a non-canonical IPv4 endpoint. Per the 24.22.1 notes, TLS now rejects non-canonical IP addresses.
CVE-2026-105483: another TLS hostname bypass, this time when an IP address is written in fullwidth digits. It is listed as an IP normalization regression and affects 26.x and 24.x only.
CVE-2026-105482: dns.resolve truncated names containing a NUL character. It affects all three lines.

The medium fixes cover a keep-alive socket processing a response written before its request was sent (CVE-2026-105481). The other one, CVE-2026-106074, is easy to miss. crypto.randomUUID() and randomInt() entropy caches were saved into user-land startup snapshots and single executable applications, "so every process repeats the same values." The low fixes are two Permission Model bypasses (CVE-2026-106071 and CVE-2026-106073) and a ZipFile prefix-bytes issue on 26.x (CVE-2026-106070).

Who is affected

Anyone running Node.js 22.x, 24.x or 26.x before the fixed versions is affected. The project notes that End-of-Life lines "are always affected when a security release occurs" and get no fix, so anything on 20.x or older should move to a supported LTS. That also covers Node.js bundled into container images, desktop apps and SEAs, which only get the fix when they are rebuilt.

Do you really need to act?

Yes, on a normal patch cadence. No exploitation is reported, none of these CVEs is in CISA KEV, and the project published no CVSS scores, only severity ratings. Priority depends on what your services do:

Brotli (CVE-2026-111497) matters most if your code decompresses Brotli data an attacker can influence, for example br-encoded bodies or files decoded with the zlib Brotli APIs. Memory corruption in a parser that handles network input is the one item here that could become serious fast.
The TLS hostname issues matter for clients that connect to hosts named by IP address, or that accept attacker-influenced hostnames, such as webhooks, URL fetchers and proxies. The risk is a certificate being accepted for the wrong endpoint, which helps an attacker already positioned on the network path.
Snapshot/SEA entropy (CVE-2026-106074) matters only if you build startup snapshots or SEAs. Then every process could hand out the same "random" UUIDs, which is bad for anything that uses them as identifiers or tokens.
Permission Model fixes matter only if you rely on --permission as a sandbox.

What to do now

Inventory runtimes: run node -v on hosts, in CI runners and inside images (docker run --rm your-image node -v).
Upgrade: nvm install 24.22.1 (or 22.23.4 / 26.12.1), your OS package manager, or refreshed official node:* images. Then restart every Node process.
Rebuild and redeploy images, Electron-style bundles you control, and SEAs. Restarting an old image does not patch it.
If you ship startup snapshots or SEAs that call crypto.randomUUID() or crypto.randomInt(), rebuild them on a fixed release. Review whether any identifiers they generated were relied on to be unique or secret.
Plan migration off any End-of-Life line.

How to tell if you were hit

There is no public exploitation to hunt for. The practical check is exposure. Compare node -p process.versions.node against the fixed versions across your fleet and image registry. As a weak signal for the Brotli bug, look for Node processes crashing while handling compressed traffic. If you shipped snapshot-based binaries, check logs or databases for duplicate UUIDs generated by different processes. That pattern is the visible symptom of CVE-2026-106074.

Timeline

Oct 21, 2026 — The Node.js project publishes its October security release advisory. Node.js 26.12.1, 24.22.1 and 22.23.4 are released the same day with fixes for ten CVEs.

Sources

Act now: LiteLLM 1.107.0: Malicious PyPI and Docker Release

erroneo.us Security Desk — Wed, 21 Oct 2026 00:00:00 -0700

Verdict: Act now. Check right now whether anything installed litellm 1.107.0 or pulled a LiteLLM image by a floating tag on October 21; if it did, assume every secret that host could read is stolen.

Who must act: Anyone whose laptops, CI runners, containers or Kubernetes nodes resolved litellm (unpinned or >=) or a latest/main-* LiteLLM image between about 11:39 and 14:20 UTC on October 21, 2026.
Who can relax: Teams pinned to 1.106.2 or earlier by hash/lockfile, image users pinned by digest to a pre-incident image, and LiteLLM Enterprise private-registry customers, which LiteLLM says were not affected.

Find exposure: pip show litellm, grep lockfiles and CI logs for 1.107.0, and list running image digests.
On any hit, isolate the host or container and preserve evidence; do not run that environment's python or pip first.
Kill the detached daemon holding /tmp/remote_code_loader.lock and delete cook.pth, cook.py, sitecustomize.py (and their .pyc) from site-packages, or better, destroy and rebuild the environment.
Reinstall pinned to litellm==1.106.2 with hashes, and pin images by digest.
From a clean machine, rotate everything the host could reach: cloud role/keys, every provider key in the LiteLLM DB plus master/virtual keys, DATABASE_URL, GitHub/npm/PyPI tokens, SSH/GPG keys, AI-tool sessions.
Review CloudTrail/cloud audit logs for sts:GetCallerIdentity and Bedrock ListFoundationModels from unfamiliar IPs, including 168.100.8.57 and 165.227.201.8.

What happened

On October 21, 2026, an attacker published litellm==1.107.0 to PyPI and pushed matching container images. LiteLLM is a widely used Python SDK and proxy that fronts dozens of LLM providers, and Datadog cites about 23 million weekly downloads. According to LiteLLM's incident report, all seven 1.107.0 wheels were live from 11:39:51 UTC to about 13:23 UTC. On Docker Hub and GHCR, the tags v1.107.0, latest, main-latest and main-stable pointed to malicious image indexes from 11:46:56 UTC. They were withdrawn from GHCR by 13:51 and from Docker Hub by 14:20. The official GitHub v1.107.0 source tag is clean. The artifacts were built from a lookalike repository, Berri-AI/litellm (one hyphen), rather than BerriAI/litellm.

LiteLLM's current understanding is that stolen GitHub CLI OAuth tokens belonging to three engineers were used for four steps: altering a release workflow, overriding branch protection, satisfying a production approval gate, and deleting workflow records afterward. It suspects, but has not confirmed, that the initial access came through an internally exposed LiteLLM deployment. LiteLLM says the private Enterprise release and registry were not affected.

Who is affected

You are affected if any machine installed 1.107.0 or ran one of the affected image digests. That includes unpinned pip install litellm in CI, a litellm>= constraint that resolved that morning, or a Kubernetes deployment that pulled :latest or :main-stable. Each wheel drops three files into site-packages, as Socket and Datadog both document:

cook.pth. Python runs .pth files at every interpreter start, so the stealer fires even if your code never imports LiteLLM. It fires when you run pip, too.
cook.py, the credential stealer. It targets AWS, GCP and Azure credentials (including instance metadata), Kubernetes, Vault and Terraform secrets, SSH, GPG and TLS keys, Git, npm and PyPI tokens, .env files, browser cookies and passwords, and AI-tool sessions such as ~/.claude/.credentials.json and ~/.codex/auth.json. If DATABASE_URL is set, it also reads the LiteLLM proxy's stored provider credentials.
sitecustomize.py, a loader on Linux and macOS that polls a GitHub dead drop every hour and would exec second-stage Python from it. Researchers saw no second stage served before GitHub removed the repository.

Do you really need to act?

Everyone needs to check. Only those who ran it need to respond. The window was about two hours, but CI pipelines and floating container tags are built to pull new releases quickly. Theft is not hypothetical. Wiz observed stolen AWS instance-role credentials from CI runners and Kubernetes nodes being validated from 168.100.8[.]57 and 165.227.201[.]8 roughly three to five hours after the release. The attackers called sts:GetCallerIdentity and then Bedrock model listing, which fits LLMjacking. If the affected host had outbound internet access, LiteLLM says to assume exfiltration succeeded. Uninstalling the package does not remove the startup files. Exfiltration is encrypted with an embedded RSA-4096 key, so you cannot tell what was taken. If you pin by lockfile hash or image digest and did not bump anything on October 21, you can relax.

What to do now

Find it. Run pip show litellm in every virtualenv and image, grep -r "litellm.*1.107.0" poetry.lock uv.lock requirements*.txt, search CI logs, and run docker images --digests | grep litellm. Compare against index sha256:1bbcb1443bc9…c339e and the per-variant indexes in the LiteLLM report.
Isolate before touching. Do not run the affected environment's python or pip, because that re-triggers the payload. Preserve disk and memory if you can.
Clean or, better, rebuild. Kill the detached process holding /tmp/remote_code_loader.lock. Delete cook.pth, cook.py, sitecustomize.py and their __pycache__ files from every site-packages directory. Then destroy the venv or image and rebuild it pinned to litellm==1.106.2.
Rotate from a clean machine. Cover the instance or task IAM role and any static cloud keys, every provider key in the proxy DB plus master and virtual keys, the DATABASE_URL password, GitHub, npm and PyPI tokens, SSH and GPG keys, and logged-in AI-tool and browser sessions.
Hunt in the cloud. Review CloudTrail and your other providers' audit logs from 11:39 UTC onward for role use outside your network.
Harden. Install with pip install --require-hashes or a uv or poetry lockfile, reference images by @sha256: digest rather than by tag, and consider a release-age cooldown before adopting new versions.

How to tell if you were hit

Artifacts that confirm execution:

litellm-1.107.0.dist-info or cook.pth in site-packages.
The upload marker /tmp/.pc_once_72129118c59f5636c0bb.
The environment variable PRIVCOLLECT_ACTIVE=1 in a process.
Egress to www.litellm[.]dev/healthcheck carrying the header X-Token: XWiA8gZNa7NcX2XRoAEb.
Requests to raw.githubusercontent.com/letters9813/pythonclient-test.

Wiz and Socket also publish wheel and payload SHA-256 hashes. Missing artifacts do not prove a host is clean, because the marker path fails on Windows and an attacker or reinstall can remove files.

Timeline

Oct 21, 2026 — 08:56–10:46 UTC: the attacker pushes commits to Berri-AI/litellm, and a workflow change at 10:08 overrides branch protection.
Oct 21, 2026 — 11:39:51 UTC: 1.107.0 is on PyPI. Malicious images are tagged from 11:46:56.
Oct 21, 2026 — Around 13:20–13:23 UTC PyPI quarantines the release. GHCR tags are gone by 13:51 and Docker Hub tags by 14:20.
Oct 21, 2026 — Around 16:20–17:01 UTC Wiz observes stolen AWS role credentials being validated. LiteLLM declares the incident contained, with the investigation ongoing.

Sources

Security digest: October 21, 2026

erroneo.us Security Desk — Wed, 21 Oct 2026 00:00:00 -0700

3 editorial briefs and 3 critical advisories.

Critical advisories

Act now: Plex2Shell: Exploited RCE Chain in Plex Media Server

erroneo.us Security Desk — Tue, 20 Oct 2026 00:00:00 -0700

Verdict: Act now. A public proof of concept chains four Plex bugs into code execution without credentials, and attackers have used it since October 17: update any internet-reachable server now, then check it for a miner or proxy.

Who must act: Anyone running Plex Media Server older than 1.43.3.10861 that is reachable from the internet, including NAS and Docker installs.
Who can relax: Servers already on 1.43.3.10861 or later; LAN-only servers are far less exposed but should still update.

Check the full build number in Settings > General, or run curl -s http://127.0.0.1:32400/identity on the server.
Update to Plex Media Server 1.43.3.10861 or later; on Docker, pull plexinc/pms-docker and recreate the container.
Turn off Remote Access and remove any port 32400 forward if you do not need outside access.
Preserve the Plex logs, then check Preferences.xml, the Codecs folder and outbound traffic for the indicators below.
If anything turns up, rebuild from a clean install, sign out all devices, change the Plex password and rotate credentials for shares the server could reach.

What happened

On October 16, 2026, researcher Zach Main published Plex2Shell, a write-up and proof of concept that chains four Plex Media Server (PMS) bugs into code execution without any credentials. The next morning a honeypot run by BoredHackerBlog recorded the first exploitation in the wild. On October 19 Plex said in its security thread that the flaws are "actively and widely exploited." On October 20 CISA added all four CVEs to the KEV catalog.

The chain, as the researcher describes it:

CVE-2026-96652: /player/timeline checks only that an X-Plex-Token header exists, not that it is valid. A crafted protocol parameter makes the server POST to any URL, including its own loopback interface (CVE record).
CVE-2026-96654: loopback requests skip authentication on the internal /system/agents API, and searchOne does not neutralize URL values, so the attacker can call other plugins' functions.
Owner token theft: PMS attaches the owner's admin token to outbound requests whose URL starts with http://127.0.0.1. Because that is a prefix match, a hostname like 127.0.0.1..sslip.io receives the token.
CVE-2026-96656: with that token, the attacker sets the TranscoderH264Options preference, which PMS appends verbatim to x264's options, and triggers a transcode that writes a shared object into the Codecs folder. PMS loads every .so there at startup without signature checks (CVE record), so the code runs as the plex user.

The fourth CVE, CVE-2026-96655, is an authenticated SSRF in /video/:/transcode/universal. CISA, acting as CNA, scores the bugs individually from 4.3 to 7.2 on CVSS 3.1 (8.6 on CVSS 4.0 for the file write). The researcher scores the full chain at 9.8.

Who is affected

Every PMS build older than 1.43.3.10861, on Windows, macOS, Linux, NAS packages and Docker. The Hacker News reports that the fix shipped on August 3. One trap: Plex's September 1 notice told users to move to "1.43.3," but the 1.43.3.10828 build released July 14 predates the fix. Check the full build number, not the first three digits. Plex now says any server older than 10861 that is reachable from the internet should be presumed possibly compromised.

Plenty of servers update slowly. In September, Shadowserver counted more than 36,000 internet-exposed PMS instances still unpatched against Plex's earlier advisory (BleepingComputer).

Do you really need to act?

Yes, today, if the server is reachable from the internet. The chain needs no account, a working exploit is public, and CISA set an October 23 deadline for two of the four CVEs. What attackers install so far is a money-maker, not ransomware. BoredHackerBlog captured an XMRig miner and a tool called myawesomeproxy, fetched from 217.60.194.116. The proxy's startup banner says it may make "external use of your internet traffic." The Hacker News reports the miner talks to ota.proxystream[.]st, and that Bitsight tied another proxystream subdomain to the AISURU DDoS and proxyware botnet. A home Plex box on a residential IP is exactly what proxyware operators want. Code running as plex can also read your media libraries and any shares the server mounts, which is why Plex says to treat those credentials as exposed.

LAN-only servers are much less exposed, but the chain works from any device that can reach port 32400, so update them anyway. If your server auto-updated past 10861 before October 16, you can relax once you have confirmed the build.

What to do now

Find the exact build in Settings > General, or on the host run curl -s http://127.0.0.1:32400/identity and read the version attribute. Package installs: dpkg-query -W plexmediaserver or rpm -q plexmediaserver.
Update to 1.43.3.10861 or later. On Docker, run docker pull plexinc/pms-docker and recreate the container; restarting the old one changes nothing. NAS package centers can lag, and Plex says to install the package manually if yours does.
If you don't need outside access, turn off Remote Access and remove any direct port 32400 forward, as Plex advises.
Copy the Logs folder before you dig in. The researcher notes PMS keeps only a few log rotations.
If you find anything below, follow Plex's cleanup steps: rebuild from a clean install, empty the Codecs folder, check Preferences.xml for unknown transcoder options, sign out all devices, change the Plex password, and rotate credentials for every share the server could reach.

How to tell if you were hit

The data folder is /var/lib/plexmediaserver/Library/Application Support/Plex Media Server on Linux and /config/Library/Application Support/Plex Media Server in the official container. Call it $PMS:

grep -o 'TranscoderH264Options="[^"]*"' "$PMS/Preferences.xml". The researcher's hunt script treats a value containing dump-yuv or stats= as a hit, and an empty value as worth review, because the PoC clears the option after use.
grep -aE 'player/timeline/subscribe|searchOne|sslip\.io|nip\.io' "$PMS/Logs/"*.log. Exploit requests carry a protocol URL pointing at 127.0.0.1:32400/system/agents/.../searchOne. BoredHackerBlog saw them come from 91.92.40.202, 176.65.139.228 and 45.194.92.222 with a Python-urllib/3.10 user agent.
find "$PMS/Codecs" -type f $ -name '*.so' -o -name '*.dll' $ -newermt 2026-10-16 -ls. Legitimate codec downloads also land here, so look for names you don't recognize.
Look for processes such as xmrig, myawesomeproxy or mylovelyminer, high CPU while idle, and connections to proxystream.st.

On Linux and Docker hosts, the researcher's read-only plex2shell-hunt.sh automates these checks and includes YARA rules.

Timeline

Jul 14, 2026 — PMS 1.43.3.10828 released. It is still vulnerable.
Jul 27, 2026 — The researcher reports the chain to Plex.
Aug 3, 2026 — Fixed in PMS 1.43.3.10861 (per The Hacker News).
Sep 1, 2026 — Plex urges owners of v1.43.2 and earlier to update.
Sep 23, 2026 — The four CVEs are published.
Oct 16, 2026 — The Plex2Shell write-up and PoC go public.
Oct 17, 2026 — First exploitation seen in the wild, dropping a miner and proxyware.
Oct 19, 2026 — Plex confirms wide exploitation and names 1.43.3.10861 as the first unaffected build.
Oct 20, 2026 — CISA adds CVE-2026-96652, -96654, -96655 and -96656 to KEV (due Oct 23 and Nov 3).

Sources

Patch this week: eMudhra CA Key Compromise: Update Non-Browser TLS Clients

erroneo.us Security Desk — Tue, 20 Oct 2026 00:00:00 -0700

Verdict: Patch this week. Anyone can mint certificates from these broken CA keys, but only clients that skip Certificate Transparency and still trust the emSign root are exposed, and only to an on-path attacker: update those trust bundles this week, build machines first.

Who must act: Teams running Python (pip, certifi, requests, uv), Go, Java, Node.js, Rust rustls or distro CA bundles in servers, containers and CI, plus macOS users of the built-in curl, git and python3.
Who can relax: Browser users: Chrome, Firefox, Safari and Edge blocked the certificates by October 20 and enforce Certificate Transparency, where no certificate from these intermediates was logged before the block.

Upgrade pip to 26.2.2 first (install the wheel by checksum as the Python announcement shows), then certifi to 2026.10.19 and uv to 0.13.4.
Update the OS CA bundle (apt-get install --only-upgrade ca-certificates, apk upgrade ca-certificates, dnf update ca-certificates) and rebuild images on refreshed base images.
Move Go to 1.27.3 or 1.26.10, Node.js to 22.23.4, 24.22.1 or 26.12.1, and rustls webpki-roots to 1.0.10, then rebuild binaries that embed them.
Apply OpenJDK's fix for CVE-2026-91403, or add the eight intermediates to the JDK's blocked.certs.
On macOS, apply the disclosure site's /etc/ssl/cert.pem workaround for the built-in curl, git and python3, or use tools with updated bundles.
Check whether your own servers' certificates chain to emSign ECC Root CA - G3; clients that update will reject them.

What happened

On October 17, 2026, a researcher reported that the private keys of eight intermediate certificate authorities run by eMudhra, an Indian CA, could be recovered by anyone. Six of the eight issue TLS certificates and two issue code-signing certificates. Mozilla's analysis in bug 2083449 found that all eight P-384 keys "used integers less than 256," so the key can be read straight off the public certificate. eMudhra says a code flaw during an April 30, 2025 key ceremony created a second, weaker key pair, and those keys were used "by mistake to create the csr (because the key labels were similar)." Mozilla wrote that "the impact of this incident could not be higher" and that multiple people had recovered the keys independently.

With one of these keys, an attacker can issue a certificate for any hostname. The intermediates chain through Sectigo cross-signs and the emSign ECC Root CA - G3 root to the Mozilla, Apple, Microsoft and Chrome trust stores, and to the many bundles copied from them. Mozilla, Chrome and others made the details public on October 20 in a dev-security-policy thread and on a community disclosure site.

Who is affected

Not browsers. Chrome blocked the TLS intermediates by SPKI hash through CRLSets on October 17, and Firefox blocked them through OneCRL that evening. Apple followed on October 19 and Microsoft on October 20. Chrome adds that no TLS certificate chaining to these CAs was logged to Certificate Transparency before the block, so CT-enforcing browsers could not have accepted a forged one.

Everything that ships its own copy of the roots and skips CT or revocation checks. That is most developer tooling:

Python: certifi (behind requests, urllib3 and the python.org macOS installer) before 2026.10.19. Christian Heimes notes in the Python announcement that pip always loads its vendored certifi in addition to the system store, so fixing the OS is not enough below pip 26.2.2. uv before 0.13.4 is affected through its vendored webpki roots (GHSA-hq85-5cpj-mr62).
Go: Go 1.27.3 and 1.26.10 make crypto/x509 filter out chains containing these intermediates (CVE-2026-111943).
Java: OpenJDK's October 21 advisory (CVE-2026-91403, CVSS 9.1) lists 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33, 8u512 and earlier as affected.
Node.js, Rust and others: the disclosure site's patch table lists Node.js 22.23.4, 24.22.1 and 26.12.1, rustls webpki-roots 1.0.10, Deno 2.9.8, Electron 44.9.1, Composer ca-bundle 1.4.16 and many more.
Operating systems: distro ca-certificates packages (Debian, Ubuntu, Alpine, Fedora, Arch and others have shipped updates), and on macOS the built-in curl, git and python3, which read /etc/ssl/cert.pem without checking revocation. Apple had not updated that file at the time of the disclosure.

Do you really need to act?

Yes, but this week, not tonight. To exploit this, an attacker must be on the network path: hostile Wi-Fi, a compromised router or proxy, DNS hijacking, or a foothold in your cloud network. If they are, an unpatched pip install or Go service will accept a forged certificate for any host. That turns network position into tampered packages or stolen API tokens. No attacks are known, but the disclosure site says plainly that nobody knows whether anyone exploited the flaw against non-CT clients since April 2025. Prioritize build machines, CI runners and anything that installs packages or handles credentials over shared networks.

There is a second, operational risk. Mozilla and Chrome are removing trust in emSign ECC Root CA - G3 altogether. eMudhra estimates "about 30,000 certs that require migration." If your own services use certificates from that hierarchy, updated clients will start refusing to connect.

What to do now

Python: upgrade pip first. The announcement shows installing the 26.2.2 wheel by URL with a pinned SHA-256, so the upgrade itself doesn't depend on the old bundle. Then run python -m pip install -U 'certifi>=2026.10.19', update uv to 0.13.4 (UV_SYSTEM_CERTS=true uv self update on a patched OS), and bump certifi in lockfiles.
Update OS bundles (apt-get install --only-upgrade ca-certificates, apk upgrade ca-certificates, dnf update ca-certificates), then rebuild container images on refreshed bases. The Python thread notes that the official Python Docker images still shipped pip 26.2.1 on October 21.
Roll Go, Node.js and Java to the fixed releases and rebuild statically linked binaries. For JDKs you can't update yet, OpenJDK says to block the certificates in blocked.certs.
On macOS and Linux hosts that can't be updated yet, the disclosure site documents commands that distrust the affected roots in the system store.
Check the issuer chain of your own public certificates, for example with openssl s_client -connect host:443 -showcerts, and migrate any that chain to emSign ECC Root CA - G3.

How to tell if you were hit

First, find out whether each client is still exposed: curl https://dv-g3b-emudhra.we-have-a-problem.com/ succeeds only if the client still trusts the compromised chain, and a certificate error means it is fixed. Run the same request from Python, Go or Java inside your images, not just from your shell. To look for actual misuse, search TLS inspection proxies and Zeek x509.log for certificates issued by "EM DV/OV/EV TLS CA - G3B" or "G3C". eMudhra says almost no end-entity certificates were issued from these intermediates, so any hit deserves investigation.

Timeline

Apr 30, 2025 — eMudhra's key ceremony produces the flawed keys.
Oct 17, 2026 — The flawed keys are found and reported to the root programs at 18:05 UTC. Chrome ships a CRLSet block at 19:45 UTC, and Mozilla's OneCRL block completes at 22:59 UTC.
Oct 18, 2026 — eMudhra revokes the eight intermediates.
Oct 19, 2026 — Downstream trust stores are notified, Sectigo's cross-signs are revoked, Apple blocks the certificates, and Go 1.27.3 and 1.26.10 ship.
Oct 20, 2026 — Public disclosure. Microsoft blocks the certificates, Mozilla removes the root from NSS, and pip 26.2.2, uv 0.13.4 and certifi 2026.10.19 advisories land.
Oct 21, 2026 — Node.js security releases and the OpenJDK advisory ship. Fixes for Bun and Erlang certifi are still pending.

Sources

Security digest: October 20, 2026

erroneo.us Security Desk — Tue, 20 Oct 2026 00:00:00 -0700

2 editorial briefs, 6 known exploited (cisa kev) additions and 3 critical advisories.

Known exploited (CISA KEV)

CVE-2026-96656 Plex Media Server: Plex Media Server External Control of File Name or Path Vulnerability (due 2026-10-23)
CVE-2026-96655 Plex Media Server: Plex Media Server Server-Side Request Forgery (SSRF) Vulnerability (due 2026-11-03)
CVE-2026-96654 Plex Media Server: Plex Media Server Improper Neutralization of Encoded URI Schemes in a Web Page Vulnerability (due 2026-10-23)
CVE-2026-96652 Plex Media Server: Plex Media Server Server-Side Request Forgery (SSRF) Vulnerability (due 2026-11-03)
CVE-2026-110936 Siemens Software Center: Siemens Software Center Uncontrolled Search Path Element Vulnerability (due 2026-11-03)
CVE-2026-106931 EG Secure Solutions SiteGuard Server Edition: EG Secure Solutions SiteGuard Server Edition OS Command Injection Vulnerability (due 2026-10-23)

Critical advisories

Security digest: October 19, 2026

erroneo.us Security Desk — Mon, 19 Oct 2026 00:00:00 -0700

2 critical advisories.

Critical advisories

Act now: ConnectWise Cloud Backup: App Credential Abused in M365

erroneo.us Security Desk — Fri, 16 Oct 2026 00:00:00 -0700

Verdict: Act now. If any tenant you run or manage ever consented to a ConnectWise or SkyKick app, disable those apps and audit the tenant today; attackers used the vendor's own credential to sign in as the app, so MFA did not stop them.

Who must act: MSPs and organizations that use ConnectWise Cloud Backup (formerly SkyKick), Cloud Management or SaaS Security for Microsoft 365, including tenants that inherited these apps from a previous provider.
Who can relax: Microsoft 365 tenants with no ConnectWise or SkyKick enterprise applications, and Google Workspace-only customers, with no evidence of exposure in the reporting so far.

In every tenant, disable (do not delete) the ConnectWise Cloud Backup and ConnectWise/SkyKick Cloud Management enterprise apps by setting 'Enabled for users to sign-in?' to No.
Remove any directory role a ConnectWise or SkyKick service principal holds that you did not grant, especially Global Administrator and Exchange Administrator.
Review client secrets and certificates on every enterprise app and app registration for anything added since Oct 13, 2026 that you did not create, and remove it.
Check mailboxes for new forwarding, inbox rules and delegated access, and review Conditional Access exclusions and federation trusts.
Export sign-in and audit logs now, especially on Entra ID Free with 7-day retention, and enable Microsoft Graph activity logs going forward.
Keep the apps disabled until ConnectWise issues formal reconnection instructions for your service.

What happened

An attacker got hold of an application credential for ConnectWise Cloud Backup, the Microsoft 365 backup service formerly called SkyKick, and used it to sign in to customer tenants as the backup app. According to the ConnectWise Trust Center advisory, the company discovered the issue on October 14, 2026. On October 17 at 07:00 UTC it disabled seven application identities and revoked the certificates behind them. It also suspended Cloud Backup, SaaS Security and Cloud Management. ConnectWise says it completed a full reset of accounts and credentials in the affected environment on October 19, and phased restoration began on October 21.

The OAuth client-credentials flow involves no user, so MFA never came into play. Huntress reported token-issuing sign-ins from 144.172.64[.]128 on October 15 and confirmed unauthorized sign-ins in 162 tenants by 19:00 UTC on October 16. A later update counted almost 1,000 Entra tenants with sign-ins from that address, over 300 of them successful. In about 50 tenants it monitors, Huntress saw ConnectWise Cloud Management service principals grant themselves directory roles, mostly Exchange Administrator. In one tenant, the "Cloud Management - MS Teams" app made itself Global Administrator and added client secrets, set to expire in 2028, to two other apps. One of them was Huntress's own application. Huntress says it then removed that credential.

In an October 21 update, ConnectWise said that the evidence, including threat intelligence shared by Microsoft, points to a China state-aligned group. According to ConnectWise, the group used an openly available agentic AI framework to automate the operation. How the credential was stolen was not disclosed as of October 21, 2026.

Who is affected

Any Microsoft 365 tenant that consented to ConnectWise Cloud Backup (app ID 506e08f9-6e9a-4da4-942b-a099a03644ae) or the related Cloud Management apps is at risk. In older tenants these may appear as "SkyKick Cloud Manager". The backup app's existing consent covers reading and writing mail, OneDrive and SharePoint files, and Teams chats. BleepingComputer reports that Microsoft Threat Intelligence called it an "active supply-chain attack" that likely abused existing permissions, including Directory.ReadWrite.All. Many tenants are run by MSPs, so a single partner may have dozens of exposed customers.

Do you really need to act?

Yes, if those apps exist in your tenant, even if you no longer use the backup service. ConnectWise says backup archives "remain encrypted, isolated, and preserved, with no indication of compromise." It also says it cannot see into customer tenants, so it cannot tell you whether yours was touched. Containment on the vendor side stops new sign-ins with the old credential. It does not undo role assignments, secrets or inbox rules that were already added. ConnectWise also warns that previously issued tokens may stay usable until they expire.

The impact varied. Todyl found only sign-ins in the tenants it reviewed: no new accounts, roles or secrets. Huntress saw persistence set up in some tenants within minutes. Reads made through the backup app are hard to tell apart from normal backup traffic, and Graph directory reads leave no audit record. Absence of evidence is weak comfort here.

What to do now

Disable the apps in every tenant you manage. In Entra, open Enterprise applications, then Properties, and set "Enabled for users to sign-in?" to No, or run Update-MgServicePrincipal -ServicePrincipalId -AccountEnabled:$false. Disable rather than delete, so consent and evidence survive.
Find every ConnectWise or SkyKick service principal, for example with Get-MgServicePrincipal -Filter "appId eq '506e08f9-6e9a-4da4-942b-a099a03644ae'", plus the Cloud Management app IDs Huntress lists.
Remove directory roles you did not grant, then audit client secrets and certificates on all apps for additions since October 13.
Check Exchange for forwarding, inbox rules (Get-InboxRule -Mailbox ) and delegated access, and review Conditional Access exclusions and federation trusts.
Export logs before retention expires, and keep the apps disabled until ConnectWise issues reconnection instructions for your service.

How to tell if you were hit

The default user sign-ins view will not show this activity. Open the Service principal sign-ins tab and filter on the Cloud Backup app ID. Flag 144.172.64.128, any non-Microsoft address, and the user agents Python-urllib/3.12, python-requests/2.31 and kiota-dotnet. In audit logs, search for "Add member to role", "Update application" and "Add service principal credentials" initiated by these apps. Huntress also lists 144.172.64.99, 144.172.64.60 and 144.172.94.243 for password spraying. Any hit means you should treat mail, files and Teams data in that tenant as possibly exposed.

Timeline

Oct 13, 2026 — Huntress sees password spraying against law-firm tenants from the attacker's address range (Oct 13–14).
Oct 14, 2026 — ConnectWise discovers the problem and starts incident response.
Oct 15, 2026 — Service principals self-assign directory roles from 01:58 UTC, and token sign-ins from 144.172.64.128 sweep tenants in GUID order.
Oct 16, 2026 — ConnectWise posts its advisory, and Huntress and Todyl publish findings.
Oct 17, 2026 — ConnectWise disables seven app identities and suspends Cloud Backup, SaaS Security and Cloud Management (Cybersecurity Dive).
Oct 19, 2026 — Full credential reset completed in the Cloud Backup environment.
Oct 21, 2026 — Phased restoration begins, and ConnectWise attributes the attack to a China state-aligned group.

Sources

Patch this week: Pillow 13.0.0: Critical Image-Parsing Memory Bugs Fixed

erroneo.us Security Desk — Fri, 16 Oct 2026 00:00:00 -0700

Verdict: Patch this week. If your service opens images that users or the internet supply, move to Pillow 13.0.0 this week; the worst bugs are memory corruption reachable from a crafted file, and reproducers are in the published advisories.

Who must act: Any Python service that opens, thumbnails or re-saves untrusted images with Pillow, such as upload handlers, CMS and Django media pipelines, document converters and ML data loaders.
Who can relax: Code that only processes trusted, locally generated images, and Pillow builds older than 11.0.0 for the MPO/PSD bug (they still need 13.0.0 for the others).

Find every Pillow install: pip show pillow, or pip list | grep -i pillow, in each image and virtualenv.
Upgrade with pip install --upgrade 'pillow>=13.0.0', then rebuild and redeploy containers.
Services still on Python 3.10 cannot install 13.0.0: plan the Python upgrade, and apply the workarounds meanwhile.
Until upgraded, call img.load() before thumbnail() or pass reducing_gap=None, and restrict Image.open(formats=[...]) to the formats you need, excluding EPS, PSD, MPO, DCX and MIC.
Never pass user-controlled filenames to Image.open(); open uploads as file objects or from server-generated paths.
Check distro python3-pil packages separately; Debian stable releases were still unfixed as of Oct 21, 2026.

What happened

On October 16, 2026, the Pillow project released Pillow 13.0.0. Its security section lists dozens of fixes, mostly in image decoders and encoders, with severities from critical to low. The repository advisories went public on October 17, and the CVE records followed on October 19 and 21. These four are the ones to read first:

CVE-2026-96639 (GHSA-v9pv-5gc8-w2m6, CVSS 3.1 9.8). Multi-frame loaders can reuse native storage sized for a narrower frame after a later frame changes mode. Per the CVE record, crafted PSD, MPO, DCX or MIC files then write past the allocation. The record says the MPO path can also reach command execution "in demonstrated runtime-specific profiles". The reporter notes this is not universal RCE. It affects 11.0.0 through 12.3.0.
CVE-2026-112403 (GHSA-8g5g-8vmr-9782). thumbnail() calls draft(), which asks libjpeg for downscaled output. Lossless (SOF3) JPEGs ignore that request under libjpeg-turbo 3.x, so full-width rows overflow a smaller heap buffer. The advisory says official Pillow wheels bundle libjpeg-turbo 3.x. Builds on libjpeg-turbo 2.x or IJG libjpeg reject the file. Restricting Image.open(..., formats=["JPEG"]) does not help, because the file is a valid JPEG. The report credits Anthropic's Claude for the find, validated by Ada Logics.
CVE-2026-112393 (GHSA-332p-7hrc-92wf). Re-saving a TIFF to an in-memory target such as io.BytesIO can write attacker-supplied tag bytes past a heap buffer and leak stale heap bytes. Saves to real file paths are unaffected. The bug dates back to Pillow 2.0.0 (2013).
CVE-2026-112900 (GHSA-w889-685w-c8fh). For EPS files, Pillow passes the filename to Ghostscript unsanitized. A name beginning with - or @ injects Ghostscript arguments even with -dSAFER. Command execution also requires an @ argument file the attacker controls.

Severity labels disagree between sources. The CVE records score the last three 9.2 (CVSS 4.0). Pillow's own advisories label the JPEG bug High and the EPS bug Moderate, and the release notes rank the EPS bug Medium.

Who is affected

Anyone running Pillow 12.3.0 or earlier on images they did not create. That includes upload handlers that generate thumbnails, CMS media libraries, PDF and document converters, and ML pipelines that read scraped datasets. Pillow 13.0.0 requires Python 3.11 or later, and PyPI has no 12.x security release, so Python 3.10 services have no upstream fix. As of October 21, the Debian tracker shows bookworm, trixie and forky still vulnerable, with only sid fixed (13.0.0-1).

Do you really need to act?

Yes, if untrusted images reach Pillow. Each bug fires from file contents during routine calls such as open(), seek(), thumbnail() and save(), not exotic APIs. The JPEG bug needs no special format at all. Reproducers are attached to the public advisories, and CISA's enrichment of CVE-2026-112393 records a proof of concept. No in-the-wild exploitation was reported as of October 21, 2026, and none of these CVEs is in CISA KEV. The EPS bug is narrower: it needs an attacker-influenced filename, and Ghostscript must be installed.

What to do now

Inventory: pip show pillow in every virtualenv and image, and pip-audit where you use it.
Upgrade: pip install --upgrade 'pillow>=13.0.0', pin it in requirements or lock files, and rebuild containers. Review 13.0.0's breaking changes first, such as the dropped Python 3.10 support and the removed Image._show.
Until you can upgrade, per the JPEG advisory, call img.load() before thumbnail() or pass reducing_gap=None. Open uploads with an explicit formats= list that leaves out EPS, PSD, MPO, DCX and MIC unless you need them.
Never pass user-supplied filenames to Image.open(). Open a file object or a server-generated path instead.
Run image decoding in a separate, low-privilege worker without network egress, so a memory-corruption bug stays contained.

How to tell if you were hit

Check versions with python3 -c "import PIL; print(PIL.__version__)". Check the bundled JPEG library with features.version('libjpeg_turbo') from the features module. In logs, look for image workers that segfault or abort with glibc heap errors such as malloc(): corrupted top size, especially if one upload triggers it repeatedly. Look for Ghostscript (gs) or shell processes spawned by Python workers that should not run them. Treat a worker that crashed on attacker-supplied files as possibly compromised, and rotate the secrets it could read.

Timeline

Oct 16, 2026 — Pillow 13.0.0 is released on PyPI.
Oct 17, 2026 — Pillow publishes the repository security advisories.
Oct 19, 2026 — CVE-2026-112393, CVE-2026-112403 and CVE-2026-112900 are published.
Oct 20, 2026 — GitHub's advisory database lists the first critical advisory, with more following Oct 21.
Oct 21, 2026 — CVE-2026-96639 is published.

Sources

Security digest: October 16, 2026

erroneo.us Security Desk — Fri, 16 Oct 2026 00:00:00 -0700

2 editorial briefs, 2 known exploited (cisa kev) additions and 2 critical advisories.

Known exploited (CISA KEV)

CVE-2026-102764 BeyondTrust Remote Support: BeyondTrust Remote Support Authentication Bypass by Spoofing Vulnerability (due 2026-10-19)
CVE-2025-61624 Fortinet Multiple Products: Fortinet Multiple Products Path Traversal Vulnerability (due 2026-10-19)

Critical advisories

Act now: BeyondTrust Remote Support CVE-2026-102764 Zero-Day

erroneo.us Security Desk — Thu, 15 Oct 2026 00:00:00 -0700

Verdict: Act now. If you run a self-hosted BeyondTrust Remote Support appliance, patch it today and assume it may already be compromised; an espionage group used this as a zero-day for about seven weeks.

Who must act: Organizations running self-hosted BeyondTrust Remote Support (any version through 26.2.3), and self-hosted Privileged Remote Access as a precaution.
Who can relax: Teams that do not use BeyondTrust; SaaS customers need no patch (BeyondTrust patched them by October 9) but should still review admin changes and stored credentials.

Inventory every Remote Support and Privileged Remote Access deployment, whether it is SaaS or self-hosted, and its version.
Apply BT26-05-RS to self-hosted Remote Support today (upgrade to 24.3.1 or later first if older), and confirm it in the /appliance interface.
Preserve logs and a snapshot before patching or rebooting any appliance that was internet-reachable while unpatched.
Hunt for the published indicators; rebuild from a clean, patched image if compromise is confirmed or cannot be ruled out.
After patching or rebuilding, rotate every credential stored in or brokered by the appliance, and review admin, Jump Item and Team permission changes.
Apply the precautionary patch to self-hosted Privileged Remote Access.
Forward appliance syslog to an external SIEM and alert on permission changes and forwarding gaps.

What happened

On October 15, 2026, BeyondTrust disclosed CVE-2026-102764 (advisory BT26-05) in Remote Support, the help-desk remote access product formerly called Bomgar. According to the vendor's CVE record, internal messaging components "did not adequately validate the origin of the messages" they received, which could let an attacker "perform file operations on the appliance". No login or user interaction is needed. Google's threat intelligence team says exploitation "results in the arbitrary upload of files." BeyondTrust scores it CVSS 4.0 9.3, and NVD scores it CVSS 3.1 9.8. CISA added it to KEV on October 16 with an October 19 deadline and rated it automatable.

This was a zero-day. Rapid7, summarizing BeyondTrust, reports two known compromises starting August 29, one on a BeyondTrust-hosted instance and one on a self-hosted appliance. Google Threat Intelligence Group and Mandiant attribute the activity to ARMORY CASTLE (formerly UNC5221), a suspected PRC-nexus espionage actor. CrowdStrike tracks the same actor as Warp Panda, per BleepingComputer. After getting in, the attackers did the following:

dropped the SAWFLY PHP web shell
copied /bin/sh to a root-owned SUID binary
dumped the appliance's credential vault with BeyondTrust's own bt-secrets tool
persisted through the sudoers template
exposed a SOCKS5-over-WebSocket tunneler, BARECLAW, through a modified HAProxy route
deleted logs
raised Jump Item and Team permissions to Administrator, then used support sessions to pull files from user desktops

Who is affected

Every Remote Support version through 26.2.3 is affected. Self-hosted appliances on 24.3.1 through 26.2.3 need the BT26-05-RS patch. Older appliances must first be upgraded to 24.3.1 or later. BeyondTrust says it patched all Remote Support SaaS customers by October 9 (BleepingComputer reports October 8). Privileged Remote Access (PRA) shares the affected code. BeyondTrust has not found a way to exploit it there, but released a PRA patch as a precaution and recommends self-hosted PRA customers apply it now. PRA SaaS was also patched. BleepingComputer cites Shadowserver tracking over 1,400 internet-exposed Remote Support instances.

Do you really need to act?

If you run self-hosted Remote Support, yes, today, and patching is only half the job. These appliances face the internet by design. They hold credentials for the machines your help desk supports and can open sessions into them, so a compromised appliance is a route into the whole fleet. The attacker had roughly seven weeks before disclosure, and Mandiant found logs deleted throughout the intrusion. Rapid7 stresses that patching does not remove persistence. This is also the second Remote Support flaw in KEV this year, after CVE-2026-1731 in February.

Self-hosted Remote Support: patch now, then investigate as if compromised.
Self-hosted PRA: apply the precautionary patch this week.
SaaS customers: nothing to patch, but one known victim was a hosted instance. Review admin and permission changes and rotate vault credentials.
No BeyondTrust: no exposure.

What to do now

List every Remote Support and PRA deployment, whether it is SaaS or self-hosted, and its version. Check the version in the /appliance admin interface.
Before touching an appliance that was reachable while unpatched, export logs and take a snapshot. Isolate it if anything looks wrong.
Apply BT26-05-RS (upgrade first if you are below 24.3.1), and confirm it in /appliance. Patch manually if automatic updates are off, as the Canadian Cyber Centre also advises.
If compromise is confirmed or cannot be ruled out, rebuild from a clean, fully patched image.
Only after patching or rebuilding, rotate every credential stored in or brokered by the appliance, including Vault and integrated Password Safe or PRA credentials. Review admin accounts and downstream support sessions.
Forward appliance syslog to an external SIEM over TLS. Turning forwarding on now cannot recover evidence that was already deleted.

How to tell if you were hit

Google published file indicators: mangoapi.php (SAWFLY, SHA-256 dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb) and ingredi_ws (BARECLAW, 1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462). Other artifacts include /usr/bin/dbus-authd, /home/bomgar/sbin/post_boot.d/zz-root-persist, a NOPASSWD: ALL line in /ns/config/sudoers.template, a /uidchanarge route to 127.0.0.1:19800 in /ns/config/haproxy.conf, and staging POSTs to an app_84304470%2Ephp path. In logs, look for user_changed events raising Jump Item or Team roles, admin sessions from residential or commercial VPN addresses, and gaps in syslog forwarding bounded by a single session. BeyondTrust warns that finding no known indicators does not prove an appliance is clean.

Timeline

Aug 29, 2026 — First known exploitation, against one hosted and one self-hosted instance.
Sep 28, 2026 — BeyondTrust discovers and contains the hosted compromise.
Sep 30, 2026 — Mandiant shares findings from the self-hosted investigation.
Oct 9, 2026 — BeyondTrust says all Remote Support and PRA SaaS customers are patched.
Oct 15, 2026 — BT26-05 and the CVE are published, along with Google's ARMORY CASTLE report.
Oct 16, 2026 — CISA adds the CVE to KEV. The Canadian Cyber Centre issues AL26-025.
Oct 19, 2026 — CISA's federal deadline. Rapid7 publishes its analysis.

Sources

Check exposure: Siemens Software Center DLL Flaw Abused in ClickFix Attacks

erroneo.us Security Desk — Thu, 15 Oct 2026 00:00:00 -0700

Verdict: Check exposure. Siemens users get the fix automatically, but the real threat is attackers shipping their own signed, older copy as a malware loader, so Windows defenders should block the indicators and hunt rather than rely on patching.

Who must act: Security teams with Windows endpoints, since attackers bring the vulnerable signed program themselves, and organizations that run Siemens Software Center for Siemens engineering software.
Who can relax: Teams with no Windows endpoints; Siemens Software Center users whose installs have updated to 4.0.9.8 or later and whose hunts find none of the indicators.

Start Siemens Software Center on every machine that has it so it auto-updates to 4.0.9.8 or later, and confirm the version.
Block 96.62.218[.]59, wizardexpensive[.]com and 2.27.248[.]127 on firewalls, proxies and DNS resolvers.
Hunt for SiemensSoftwareCenter.exe running from AppData\Local\Programs or launched by msiexec, and for Siemens Software Center startup entries on PCs that never had it.
Detect on folder and behavior, not on the Siemens file hash; the abused executable is genuine and validly signed.
Train users never to paste commands from a web page into Win+R, the Run box or PowerShell.

What happened

Siemens Software Center is the Windows tool that downloads, installs, activates and updates Siemens software. On October 15, 2026, Siemens published SSA-580366, a DLL sideloading flaw tracked as CVE-2026-110936 (CWE-427). Versions before 4.0.9.8 load DLLs from an uncontrolled search path. Anyone who can place a crafted DLL where the program looks can run code inside that trusted, signed process. Jose Oregon of Huntress Labs reported the issue. Siemens scores it CVSS 4.0 8.4 and CVSS 3.1 6.7. The 3.1 vector assumes local access with high privileges, which keeps the score in the medium range.

The advisory was updated on October 17 with the remediation and again on October 19 with a link to a Siemens blog post confirming active exploitation. According to Siemens, attackers took a genuine, validly signed copy of version 3.5.8.7, then the latest release, and shipped it next to their own malicious DLLs in a bundle. When the program started, it loaded the attackers' files without checking them. Siemens says its program was not modified and that "No Siemens system, product or update channel was breached to our knowledge." It attributes the activity to the Romulus multi-platform ClickFix campaign. ClickFix lures trick users into pasting a command into the Windows Run box or PowerShell. CISA added the CVE to KEV on October 20 in a six-CVE batch, with a November 3 federal deadline.

Who is affected

All Siemens Software Center versions before 4.0.9.8 are affected, per the advisory and the CVE record. Existing installations update automatically the next time they start. The bigger point is that this campaign does not need you to run Siemens software at all. The attackers bring the vulnerable signed executable with them, so any Windows PC whose user can be talked into running their command is a potential target. SecurityWeek notes that Huntress had earlier tracked a ClickFix campaign that abused signed Canon and Stardock programs the same way, in at least 40 incidents. Forescout found Romulus infrastructure on the server Siemens identified as the bundle's distribution point. Neither report names Siemens Software Center itself.

Do you really need to act?

Patching here is easy and mostly automatic, but it is not the main defense. A fixed 4.0.9.8 on your engineers' laptops does not stop an attacker from dropping an old, still-signed 3.5.8.7 into a user's AppData folder. Siemens itself tells defenders to "Detect on folder and behaviour, not on the Siemens file fingerprint." In practice:

SOC and endpoint teams: load the indicators and behavior hunts this week. This is a live malware delivery chain.
Siemens Software Center users: launch it once so it updates, and confirm the version.
Everyone else: no patch to apply. ClickFix awareness and application control matter more than this CVE.

What to do now

On machines with Siemens Software Center, start the application to trigger the update to 4.0.9.8 or later, then check the version in the app or in installed programs.
Block 96.62.218[.]59, wizardexpensive[.]com and 2.27.248[.]127 on firewalls, proxies and DNS resolvers. Siemens lists the first two as active payload hosting and command-and-control infrastructure.
Hunt with EDR for SiemensSoftwareCenter.exe running from AppData\Local\Programs or started by msiexec.exe, and for "Siemens Software Center" startup items or scheduled tasks on PCs that never had it installed.
If you find it, isolate the PC, stop the process first, then remove the startup entry and task and reset the user's passwords, following Siemens' order of operations.
Remind users that a real "I am not a robot" check never asks them to paste commands into Win+R or PowerShell.

How to tell if you were hit

Siemens lists these warning signs: an SM Software Provisioning Service folder under AppData\Local\Programs, an FTSuite folder containing ftc.uml under AppData\Local, and files named activate.bak or statinfosta.DB next to SiemensSoftwareCenter.exe. Also check for connections to the IP addresses and domain above, including the now-inactive distribution server, because PCs that downloaded the bundle earlier may still be infected. File hashes help for the attacker-supplied pieces: AllMyBasic.msi (SHA-256 f4d7c532…92e4a) and archive.dll (3fdcc7d7…cf491; full hashes are in the detection list). The Siemens executable itself is genuine, so a hash match on it means nothing. Its location and parent process are what matter.

Timeline

Oct 15, 2026 — Siemens publishes SSA-580366, and the CVE is published.
Oct 17, 2026 — The advisory is updated with the 4.0.9.8 remediation.
Oct 19, 2026 — Siemens confirms active exploitation and publishes indicators.
Oct 20, 2026 — CISA adds CVE-2026-110936 to KEV.
Nov 3, 2026 — Federal remediation deadline.

Sources

Security digest: October 15, 2026

erroneo.us Security Desk — Thu, 15 Oct 2026 00:00:00 -0700

2 editorial briefs, 1 known exploited (cisa kev) addition and 6 critical advisories.

Known exploited (CISA KEV)

CVE-2026-21589 Atlassian Multiple Products: Atlassian Multiple Products Files or Directories Accessible to External Parties Vulnerability (due 2026-10-18)

Critical advisories

Patch this week: Next.js: Two Critical Unauthenticated RCEs (Oct 14)

erroneo.us Security Desk — Wed, 14 Oct 2026 00:00:00 -0700

Verdict: Patch this week. Self-hosted Next.js apps should move to 16.4.1 or 15.5.28 this week; both RCEs have preconditions and no exploitation is reported, but the fix is a routine minor upgrade.

Who must act: Teams running self-hosted Next.js on glibc Linux with the built-in Image Optimization API, and any Next.js 16 App Router app using Cache Components.
Who can relax: Static exports with no Next.js server, apps on Alpine/musl without the image optimizer in play, and apps not using 'use cache' still should upgrade but need not drop everything.

Upgrade: npm install next@16.4.1 (16.x) or next@15.5.28 (15.x), then rebuild and redeploy.
Confirm the resolved sharp is 0.35.5 or later: npm ls sharp.
If you use React Server Components outside Next.js, upgrade react-server-dom-* to 19.0.9/19.1.10/19.2.9/19.3.1.
If you are stuck on an older Next.js line, force sharp >= 0.35.5 via overrides/resolutions and patch system librsvg.
Rebuild container images so the new node_modules and OS libraries actually ship.

What happened

On October 14, 2026, Vercel shipped an out-of-band Next.js security update, versions 16.4.1 (Active LTS) and 15.5.28 (Maintenance LTS). It fixes two critical unauthenticated remote code execution bugs and one high-severity denial of service, all rooted in upstream dependencies. Vercel had pre-announced the release on October 8. Two of the fixes were held back from the September release while upstream projects coordinated.

GHSA-673q-mjm6-r5xr (CVSS 4.0 9.5). In App Router apps that use Cache Components, a use cache function that returns multiple typed arrays can be abused for unauthenticated RCE, per the advisory. The root cause is in React's Flight protocol, tracked as GHSA-xqc2-xf4c-x3h3 in react-server-dom-webpack, -turbopack and -parcel. It affects Next.js 16.0.0 through 16.4.0. There is no workaround, and Vercel says to upgrade "even if your application does not have similar functions."
CVE-2026-96889 / GHSA-2464-fhr4-w9xw (CVSS 4.0 9.5). A memory bug in an upstream library used by the Image Optimization API can lead to RCE when Next.js runs on glibc-based Linux, per the advisory. The CVE record describes a use-after-free in librsvg, triggered by SVG documents with nested XIncludes and duplicate entity declarations. Next.js reaches librsvg through sharp. Affected versions run from 10.0.0 through 15.5.27 and 16.x through 16.4.0. The fix requires sharp 0.35.5 or later.
GHSA-p3m5-59mp-jv5r (High). Crafted requests to App Router apps with at least one Server Action can pin the CPU and stall the process.

Who is affected

The image-optimizer bug has the widest reach. next/image and the /_next/image endpoint are on by default in almost every self-hosted Next.js app, across a decade of versions. The use cache bug is limited to Next.js 16 apps that opted into Cache Components. Apps built with other frameworks on React Server Components, such as Waku, Parcel or custom setups, need the react-server-dom-* 19.x patch releases.

Do you really need to act?

Patch this week. This is not React2Shell again. Both RCEs carry the CVSS "attack requirements present" flag. The cache bug needs a specific return shape that React calls "rare." The image bug needs glibc Linux and an SVG the optimizer will process. Neither advisory reports exploitation or a public exploit, and neither is in CISA KEV. Still, the December 2025 React2Shell bug went from patch to mass exploitation within hours, and attackers now diff React and Next.js releases closely. The upgrade is a patch-level bump on the same minor line, so there is little reason to wait.

Vercel-hosted apps: the advisories do not say these are protected automatically. Redeploy on the fixed version anyway.
Alpine/musl images: the advisory names glibc as the condition for the image RCE. Upgrade for the other issues regardless.
Older lines (14.x and earlier): no patched Next.js release is listed. Force a fixed sharp and plan a migration.

What to do now

Upgrade: npm install next@16.4.1 or npm install next@15.5.28 (or the pnpm/yarn equivalent). Commit the lockfile.
Verify the tree with npm ls next sharp react-server-dom-webpack. sharp must be 0.35.5 or later.
On older Next.js lines, add an overrides (npm) or resolutions (yarn) entry for "sharp": "^0.35.5", and update the OS librsvg package where distros ship fixes.
Rebuild and redeploy containers. A patched lockfile in Git does not patch a running image.
If you can't deploy quickly, consider rejecting SVG sources at /_next/image with a WAF or reverse-proxy rule as a stopgap. This is our suggestion, not vendor guidance.

How to tell if you were hit

No exploitation has been reported. To check anyway:

Look for crashes or restarts of the Next.js server that line up with /_next/image requests for SVGs.
Look for unexpected child processes (sh, curl) spawned by node, and for new outbound connections from app servers.
If anything looks wrong, rotate the secrets in the server's environment, such as database URLs and API keys.

Timeline

Sep 23, 2026 — CVE-2026-96889 (librsvg) is published.
Sep 30, 2026 — The Next.js September security release ships. Two fixes are postponed for upstream coordination.
Oct 8, 2026 — Vercel pre-announces an out-of-band update with two critical issues and one high.
Oct 14, 2026 — Next.js 16.4.1 and 15.5.28 and the React 19.x patches are released, with advisories published.

Sources

Patch this week: PAN-OS CVE-2026-0322: Exploited Management-Interface RCE

erroneo.us Security Desk — Wed, 14 Oct 2026 00:00:00 -0700

Verdict: Patch this week. Patch every PAN-OS firewall and Panorama this week, and today if the management interface is reachable from the internet; the bug needs an admin login but is already being exploited.

Who must act: Anyone running PAN-OS 10.2 through 12.2 on PA-Series or VM-Series firewalls or on Panorama, most urgently where the management web interface is exposed beyond a trusted admin network.
Who can relax: Cloud NGFW and Prisma Access customers (not affected), and teams whose management interface is reachable only from a locked-down jump host can patch on a normal but prompt cycle.

List every PA-Series, VM-Series and Panorama instance and its PAN-OS version (show system info).
Upgrade to the fixed release or hotfix for your train from the vendor table, starting with any device whose management interface is internet-reachable.
Restrict the management interface to trusted internal addresses or a single jump host; remove any internet exposure.
Review admin accounts and rotate administrator passwords and API keys, since exploitation requires valid admin credentials.
If you cannot upgrade immediately and have Threat Prevention, enable Threat IDs 510046 and 510047 with the vendor's management-traffic prerequisites (limited coverage only).

What happened

On October 14, 2026, Palo Alto Networks published CVE-2026-0322, a code injection flaw (CWE-94) in the PAN-OS management web interface. An attacker who can reach that interface and holds administrator credentials can run arbitrary code as root on the firewall. The vendor found the bug internally. Its advisory states that "very limited exploitation has been observed" and lists three IP addresses linked to exploit attempts. CISA added the CVE to the Known Exploited Vulnerabilities catalog the same day, with a federal remediation deadline of October 17.

The vendor scores it CVSS 4.0 8.6 (High) when the interface is internet-reachable and 8.5 when it is limited to an adjacent network. It sets its suggested urgency to "highest". NVD rates it CVSS 3.1 7.2. The required privilege level, high, is what keeps the score below critical.

Who is affected

PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2 on PA-Series and VM-Series firewalls and on Panorama (virtual and M-Series) are affected. The vendor says no special configuration is needed to be vulnerable. Cloud NGFW and Prisma Access are not affected. Fixed builds are 12.2.4 and 11.2.16, plus hotfixes on every supported train, for example 12.1.10-h2, 11.1.16-h3 and 10.2.18-h12. Older maintenance lines get their own hotfixes, such as 11.2.7-h21 and 10.2.13-h26. The full table is on the CVE record and the advisory.

Do you really need to act?

Yes, but the urgency depends on two things: who can reach the management interface, and how well admin credentials are protected. An authenticated bug sounds tame. In practice, firewall admin credentials leak through phishing, reuse, old config backups and earlier appliance compromises. Root on a firewall gives an attacker a quiet foothold at the edge of your network, with visibility into traffic and VPN configuration.

Management interface on the internet: treat this as act-now. Palo Alto Networks says the risk is highest in this setup and recommends remediating as soon as possible.
Management limited to a jump host or admin VLAN: the attacker first needs a foothold there plus admin credentials. Patch this week.
Cloud NGFW / Prisma Access: no action needed.

The vendor lists no workaround. Threat Prevention customers can enable Threat IDs 510046 and 510047, but the vendor describes this as limited coverage. It also requires routing management traffic through a dataplane interface with SSL decryption, so it is not a practical substitute for upgrading.

What to do now

Inventory devices and versions. On each firewall or Panorama, run show system info and note sw-version.
Upgrade to the fixed build for your train (for example request system software install version 11.2.16 after download), starting with internet-exposed devices. Upgrade Panorama too.
Lock the management interface down to trusted internal IPs, following the vendor's management access best practices. Remove any permit rule that exposes it to the internet, including management profiles on public dataplane interfaces.
Rotate administrator passwords and API keys, enforce MFA for admin login, and remove stale admin accounts.
If an upgrade has to wait, enable Threat IDs 510046/510047 with the documented prerequisites, and tighten access controls in the meantime.

How to tell if you were hit

Search perimeter and firewall traffic logs for management-plane connections from 66.42.72.14, 208.83.239.114 and 149.248.47.234, the addresses Palo Alto Networks associates with exploit attempts. Review the system and configuration logs for admin logins from unfamiliar sources, newly created administrators and unexplained commits. If the interface was reachable from the internet while unpatched, treat the device as possibly compromised. Open a case with Palo Alto Networks support, export logs before rebooting, and rotate every credential stored on the device, including VPN, LDAP and RADIUS secrets. A root-level implant may not show up in configuration logs.

Timeline

Oct 14, 2026 — Palo Alto Networks publishes the advisory with fixed builds and notes limited exploitation. CISA adds CVE-2026-0322 to KEV the same day.
Oct 15, 2026 — The advisory is updated, and the CVE record gets CISA's enrichment (exploitation: active).
Oct 17, 2026 — CISA's remediation deadline for federal agencies.

Sources

Patch this week: SiteGuard WAF CVE-2026-106931: Exploited Command Injection

erroneo.us Security Desk — Wed, 14 Oct 2026 00:00:00 -0700

Verdict: Patch this week. If you run SiteGuard Server Edition, save its diagnostic data and patch this week, sooner on public web servers; the bug is exploited, but its local rating means attackers need a foothold first.

Who must act: Organizations running SiteGuard Server Edition 2.20 or later for Apache httpd, Nginx or IIS below 8.00 Update 5 (7.00 Update 6 on FreeBSD) with the default-on statistics feature, a product JPCERT/CC says is widely used in Japan.
Who can relax: Anyone not running SiteGuard Server Edition: the advisories do not list SiteGuard Proxy Edition, Cloud Edition or the SiteGuard WP Plugin, and IIS versions 3.10 through 4.00 Update 4 are not affected.

Before changing anything, download the diagnostic information from the SiteGuard web admin console and store it safely; the vendor warns that updating can erase attack traces.
Upgrade to Ver8.00 Update 5 (Ver7.00 Update 6 on FreeBSD), or apply the vendor's statistics-file patch, which also covers end-of-life versions.
If you cannot upgrade or patch yet, disable the statistics feature, which JPCERT/CC says avoids the vulnerability.
Treat every server that ran a vulnerable build as possibly rooted and review it for persistence.
Contact EG Secure Solutions support or JPCERT/CC with the saved diagnostics if anything looks wrong.

What happened

On October 14, 2026, EG Secure Solutions published an urgent alert (in Japanese). It covers an OS command injection flaw, CVE-2026-106931, in the statistics feature of SiteGuard Server Edition, a host-based web application firewall that plugs into Apache httpd, Nginx or IIS. The vendor says exploitation has already been confirmed and that the flaw can run arbitrary OS commands as root or SYSTEM. Customers with support contracts were told individually on September 29. The public alert came about two weeks later, alongside JVN#88474777 and a JPCERT/CC alert. JPCERT/CC says it has confirmed the product is widely used in Japan.

The vendor, via JPCERT/CC as CNA, scores it CVSS 4.0 8.5 and CVSS 3.0 7.8, with a local attack vector and low privileges required. The CVE record and NVD carry the same vectors. CISA added it to the KEV catalog on October 20, with an October 23 federal deadline. Its enrichment marks exploitation as active and the attack as not automatable. Neither the vendor nor JPCERT/CC has described the attackers, the victims or the entry point. BleepingComputer notes those details "remain unclear."

Who is affected

SiteGuard Server Edition Ver2.20 and later, when the statistics feature is on, which is the default:

Apache httpd, Nginx and IIS editions: versions before Ver8.00 Update 5. IIS Ver3.10 through Ver4.00 Update 4 are not affected.
Apache httpd and Nginx on FreeBSD: versions before Ver7.00 Update 6.

The advisories name only Server Edition. BleepingComputer cites a vendor claim of protecting more than 1.5 million websites. Its 500,000 figure comes from WordPress.org, which counts the separate SiteGuard WP Plugin, and the advisories do not list that plugin. As of October 21, the vendor's own website was down for precautionary maintenance tied to PHP's critical October security release, so its alert may not load. JVN and JPCERT/CC carry the same details.

Do you really need to act?

If you run SiteGuard Server Edition, yes, this week. The CVSS vector means an attacker must already be able to run something on the server, or act as a low-privileged local user, before using this bug. That is not internet-wide, unauthenticated RCE. But a host WAF lives on public web servers, where a low-privileged foothold is exactly what a web application bug or web shell provides. This flaw turns that foothold into root or SYSTEM on the machine meant to protect the site. Exploitation is confirmed, and the vendor has not said when it began. So prioritize internet-facing servers and those running PHP applications you have not patched recently.

If you do not run Server Edition, there is nothing to do for this CVE.

What to do now

Preserve evidence first. In the SiteGuard web admin console, open Diagnostic information and choose Download diagnostic information. Keep the file. The vendor warns that updating or patching may erase traces of the attack.
Upgrade to Ver8.00 Update 5 (Apache httpd, Nginx, IIS) or Ver7.00 Update 6 (FreeBSD). If an upgrade is hard, apply the vendor's patch that replaces the statistics-processing files. It is available even for end-of-life versions.
If neither can happen today, disable the statistics feature. JPCERT/CC says this avoids the vulnerability.
Review each server that ran an affected build for signs of compromise, starting with internet-facing ones.
Patch the web applications behind the WAF too, because the bug needs a local foothold that those applications may provide.

How to tell if you were hit

No public indicators exist as of October 21, 2026, so the saved diagnostic information is your best evidence. Share it with vendor support or JPCERT/CC. On Linux and FreeBSD, look for root-owned cron entries, systemd units or rc scripts, new accounts and authorized_keys entries, and unfamiliar binaries in /tmp, /var/tmp or the SiteGuard install tree. On IIS servers, review new services, scheduled tasks and local administrators. Also hunt for the foothold itself: web shells and unexpected files in web roots. If the server was compromised, rebuild it and rotate the credentials and TLS keys it held.

Timeline

Sep 29, 2026 — EG Secure Solutions notifies customers with support contracts of the flaw, fixes and patch.
Oct 14, 2026 — Public vendor alert, JVN#88474777, JPCERT-AT-2026-0032 and the CVE record are published.
Oct 18, 2026 — BleepingComputer reports the exploitation.
Oct 20, 2026 — CISA adds CVE-2026-106931 to KEV.
Oct 23, 2026 — CISA's remediation deadline for federal agencies.

Sources

Security digest: October 14, 2026

erroneo.us Security Desk — Wed, 14 Oct 2026 00:00:00 -0700

3 editorial briefs and 4 known exploited (cisa kev) additions.

Known exploited (CISA KEV)

CVE-2026-76519 Cisco Secure Email Gateway: Cisco Secure Email Gateway Relative Path Traversal Vulnerability (due 2026-10-17)
CVE-2026-105134 Ahsay AhsayCBS: Ahsay AhsayCBS Command Injection Vulnerability (due 2026-10-17)
CVE-2026-105133 Ahsay AhsayCBS: Ahsay AhsayCBS Improper Authentication Vulnerability (due 2026-10-17)
CVE-2026-0322 Palo Alto Networks PAN-OS: Palo Alto Networks PAN-OS Code Injection Vulnerability (due 2026-10-17)

Act now: Ivanti Connect Secure CVE-2026-104935: Exploited Zero-Day

erroneo.us Security Desk — Tue, 13 Oct 2026 00:00:00 -0700

Verdict: Act now. Upgrade Connect Secure today and investigate with memory and network forensics, because the Integrity Checker missed this compromise and part of the attack chain still has no fix.

Who must act: Every organization running Ivanti Connect Secure 22.8 or 25.1 builds, especially internet-facing VPN gateways.
Who can relax: Organizations without Ivanti Connect Secure; per the CVE record, ICS 22.7R2.14 and earlier is not impacted, though it is an older release line.

Upgrade to the fixed Connect Secure release named in Ivanti's advisory (25.1.3.0 per the CVE record)
Do not rely on the Integrity Checker Tool alone; capture memory and network evidence if exposure dates overlap October 1 or later
Hunt welcome.cgi requests whose X-DSCGI-PATH header does not match the URL path
Rotate credentials that passed through the VPN, including AD service accounts, since the actor harvested NTLM hashes and ran Kerberoasting
Watch for Ivanti's fix for the still-unpatched privilege escalation and apply it on release
Restrict ICS admin interfaces and alert on outbound connections from the appliance

What happened

On October 13, 2026, Ivanti disclosed CVE-2026-104935 in Connect Secure (ICS), its SSL VPN. The CVE record describes "authentication bypass by spoofing in ICS before version 25.1.3.0" that "allows a remote unauthenticated attacker to execute arbitrary commands." Ivanti's CNA score is CVSS 3.1 8.6, which reads low for unauthenticated command execution. Ivanti's October security update says it is "aware of limited exploitation in the wild" and tells affected customers to "act immediately." CISA added the flaw to the KEV catalog the same day, with a three-day federal deadline and a forensic-triage requirement.

Volexity, which found and reported the flaw, saw exploitation from October 3 against a customer's ICS that was fully patched at 22.8R2.4. The chain combined an authentication bypass in welcome.cgi, a file write and race condition in wu.cgi, and a privilege escalation in which the dsinvoked broker trusts DSCache data, yielding root. Ivanti has fixed the first two under this CVE. The privilege escalation has no fix yet; Volexity reports Ivanti expects one "in the coming weeks." Defused reportedly saw first activity on October 1, per BleepingComputer.

Volexity tracks the actor as UTA0576, a previously unknown group. It assesses with low confidence that the motive is criminal, and with medium confidence that the actor uses LLMs in its tooling. After getting in, the actor captured packets to harvest credentials and NTLM hashes, ran Kerberoasting and password spraying, and queried LDAP for LAPS passwords and BitLocker keys.

Who is affected

Sources differ on scope. NVD says ICS before 25.1.3.0 is affected and 22.7R2.14 or earlier is not. BleepingComputer lists 22.8R2.4 and earlier, 25.1.2.2 and earlier, and 25.1.1.1 and earlier. Ivanti's advisory page would not load for us, so confirm the fixed build for your branch there. Shadowserver tracked more than 5,500 exposed ICS instances, per BleepingComputer.

Do you really need to act?

Yes, if you run ICS. It is reachable without credentials on the device's public face, and it worked against a fully patched appliance. Two details raise the stakes beyond a normal patch cycle. First, the chain patches a library in memory only and restores the cache entry, so Ivanti's Integrity Checker Tool did not detect the compromise; Volexity says forensic investigation is required. Second, the actor "deployed no malware or web shell" and re-exploited the device for each command, so there may be no persistent implant to find. Exploitation is described as limited today. Given Ivanti's history (BleepingComputer counts 36 Ivanti CVEs in KEV since 2021), plan for that to change.

What to do now

Upgrade to the fixed release in Ivanti's advisory (25.1.3.0 per the CVE record).
If the appliance was exposed on or after October 1, capture memory and packet data before or alongside the upgrade. Do not treat a clean ICT result as clearance.
Rotate credentials that authenticated through or to the VPN, AD service accounts exposed to Kerberoasting, and any LAPS or BitLocker secrets the ICS service account could read.
Subscribe to Ivanti advisories and apply the privilege escalation fix as soon as it ships.
Alert on outbound connections and LDAP queries originating from the ICS appliance.

How to tell if you were hit

Volexity's indicators: many requests to /dana-na/auth/url_default/welcome.cgi with an X-DSCGI-PATH header pointing at /home/webserver/htdocs/dana/fb/smb/wu.cgi or /home/runtime/tmp/; files such as /tmp/ml.py, /tmp/mk.py, /tmp/rr.py, /tmp/spray_hits.json and /data/.icscap/h.py; a dsstatmond process (renamed tcpdump); ics-root-run-inband-*.pl under /home/runtime/tmp/; tampering in debuglog and audit.log; and contact with 108.165.147[.]64. On the internal side, look for spraying, Kerberos service-ticket requests and LDAP reads originating from the appliance's IP.

Timeline

Oct 1, 2026 — First signs of activity, per Defused.
Oct 3, 2026 — Exploitation observed by Volexity on a fully patched 22.8R2.4 appliance.
Oct 5, 2026 — Volexity begins its investigation.
Oct 13, 2026 — Ivanti discloses and patches; CISA adds the CVE to KEV.
Oct 21, 2026 — Privilege escalation in the chain still unpatched as of writing.

Sources

Patch this week: Visual Studio Copilot CVE-2026-103572: Trailing-Dot RCE

erroneo.us Security Desk — Tue, 13 Oct 2026 00:00:00 -0700

Verdict: Patch this week. If your developers use Copilot in Visual Studio or SSMS, update this week: exploitation needs only text the agent reads, and the researcher's write-up spells out the chain.

Who must act: Teams on Visual Studio 2022 17.14 before 17.14.42, Visual Studio 2026 18.10 before 18.10.4, or SSMS with Copilot, especially where agents read untrusted repositories, files or MCP server output.
Who can relax: VS Code users (not in Microsoft's affected list) and installs where Copilot is not used, though updating remains the clean fix.

Update Visual Studio with the Visual Studio Installer to 17.14.42 or 18.10.4 or later, and confirm the version in Help > About.
Update SSMS to the latest 22.x release, since Microsoft's advisory does not name a fixed SSMS build.
Inventory fleet versions with vswhere -all -property catalog_productDisplayVersion.
Review .mcp.json and settings.VisualStudio.json in solutions and user profiles for MCP servers or a ripgrep path nobody added.
Until patched, keep Copilot agent mode away from untrusted repositories, files and MCP servers.

What happened

On October 13, 2026 (Patch Tuesday), Microsoft fixed CVE-2026-103572, a code injection flaw (CWE-94) in the Copilot integration shared by Visual Studio and SQL Server Management Studio. Microsoft rates it Important, CVSS 3.1 8.8. Its FAQ explains the attack: an attacker "can deliver a malicious prompt remotely without prior access," and a user only has to interact with Copilot for the injected instructions to escalate into code execution.

Johann Rehberger, who reported it on August 4, published the technical details the same day. Copilot's agent should ask for confirmation before editing protected configuration files such as .mcp.json and settings.VisualStudio.json. The check, in Microsoft.VisualStudio.Copilot.Core.dll, compared file names as literal strings. Windows' Win32 layer drops a trailing period, so a write to .mcp.json. passed the check and still overwrote the real .mcp.json. Rehberger showed two ways to turn that into code execution:

Add a malicious server to .mcp.json, enable it via enabledMcpServers, and let the IDE launch its command.
In Visual Studio, point the ripgrep path setting in settings.VisualStudio.json at an arbitrary binary, which then runs whenever Copilot searches text.

The trigger is indirect prompt injection: instructions hidden in a file the developer opens, in repository content, or in output returned by an MCP server. Rehberger also reported a path traversal out of the trusted Extensions directory. His reading of the patch is that Microsoft added a GetFullPath call, which strips trailing dots and resolves .. before the check.

Who is affected

Microsoft's update table and the CVE record list Visual Studio 2022 17.14 before 17.14.42 and Visual Studio 2026 18.10 before 18.10.4. The advisory title also names SSMS, which shares the Copilot code, but Microsoft gives no fixed SSMS build. The SSMS 22 release notes do not mention the CVE. SSMS 22.11.0, released October 13, moved to the Visual Studio 18.11.0 base, and 22.11.1 followed on October 20. NVD still shows the CVE as undergoing analysis.

Do you really need to act?

Yes, on a normal fast cycle. Microsoft marks the CVE as not exploited and "Exploitation Less Likely", and CISA's enrichment says exploitation is "none." It is not in KEV. But the precondition is cheap: the attacker never touches the machine, only text that Copilot reads. With the write-up public (SecurityOnline covers the proof of concept), reproducing it is straightforward. The impact is code execution as the developer, which usually means source code, cloud credentials and signing keys. Teams that open third-party repositories or wire in community MCP servers should treat this as urgent.

What to do now

Update Visual Studio through the Visual Studio Installer to 17.14.42 or 18.10.4 or later. For fleets, inventory versions with vswhere -all -property catalog_productDisplayVersion.
Update SSMS to the latest 22.x release, and keep checking Microsoft's advisory for an SSMS-specific build.
Review .mcp.json files in solutions and in %USERPROFILE%, plus settings.VisualStudio.json, for servers or a ripgrep path nobody added.
Until you're patched, keep Copilot agent mode away from untrusted repositories, files and MCP servers.

How to tell if you were hit

Look for MCP server entries or enabledMcpServers changes that nobody on the team made, and for a ripgrep path in settings.VisualStudio.json that points anywhere other than the bundled binary. In EDR telemetry, look for unexpected children of devenv.exe or Ssms.exe, such as shells, scripting hosts or unknown binaries started as MCP servers. If you find any, treat the developer's credentials and tokens as exposed and rotate them.

Timeline

Aug 4, 2026 — Rehberger reports the path bypass to MSRC.
Sep 16, 2026 — Microsoft confirms the vulnerability.
Oct 13, 2026 — Patch Tuesday fix ships (17.14.42, 18.10.4). Rehberger publishes his write-up. SSMS 22.11.0 is released.
Oct 16, 2026 — MSRC adds download and KB links. The fixed builds are unchanged.

Sources

Patch this week: Windows Shell CVE-2026-96951: Exploited MOTW Bypass

erroneo.us Security Desk — Tue, 13 Oct 2026 00:00:00 -0700

Verdict: Patch this week. Roll the October 2026 Windows update out to every desktop this week; attackers are using this to make malicious attachments and downloads skip the warnings that would stop them.

Who must act: Any organization with Windows 10 or 11 endpoints, or Remote Desktop servers, where people open email attachments, chat files or downloads.
Who can relax: Linux and macOS fleets, and Windows servers nobody logs into interactively, which can follow the normal patch cycle; the attack needs a user to open a crafted file.

Deploy the October 13, 2026 cumulative update to all Windows endpoints this week and reboot.
Verify the OS build on each machine is at or above the fixed build for its version.
Patch users who handle outside files first: finance, HR, support, sales and developers.
Turn on the ASR rules that block executable content from email and scripts launching downloaded executables, in audit mode first if needed.
Quarantine rarely used attachment types such as shortcuts, disk images and scripts at the mail gateway.

What happened

On October 13, 2026, Microsoft fixed CVE-2026-96951, a command injection flaw (CWE-77) in Windows Shell that it classes as a security feature bypass. Microsoft's FAQ says an attacker who exploits it "could evade Mark of the Web (MOTW) defenses." MOTW is the tag Windows puts on files that arrive from the internet. It drives the warning prompts, Office's read-only Protected View and download blocking. In Microsoft's attack scenario, the attacker sends a specially crafted file by email or instant message, or lures the user to a site that serves one. The user still has to open it. Microsoft scores the bug CVSS 3.1 8.8 and marks it "Exploitation Detected". CISA added it to the KEV catalog the same day with an October 16 federal deadline.

Per Microsoft's October release data, this is the only CVE in the release marked as exploited. Press roundups counting "three zero-days" also include a .NET Framework bypass (CVE-2026-108398), which Microsoft lists as publicly disclosed but not exploited, and a SharePoint flaw (CVE-2026-102866), which it lists as neither. Microsoft credits four reporters: "yhw", Benoit Sevens "using Claude with Anthropic", and Riku Bamba and Yuya Chudo of Fujitsu. As of Oct 21, 2026, Microsoft has not said who is exploiting the flaw, against whom, or with which file types.

Who is affected

The CVE record and update guide list Windows 10 (1607, 1809, 21H2, 22H2), Windows 11 (23H2, 24H2, 25H2, 26H1, 26H2) and Windows Server 2012 R2, 2016, 2019, 2022 and 2025. Fixes include KB5127648 (Windows 11 24H2/25H2/26H2, builds 26100/26200/26300.9711), KB5126653 (23H2, 22631.7652), KB5127646 (26H1, 28000.3231), KB5126657 (Windows 10 21H2/22H2, 19045.7807), KB5126651 (1809 and Server 2019), KB5126868 (1607 and Server 2016), KB5126655 (Server 2022), KB5126646 (Server 2025) and KB5126836 (Server 2012 R2). Microsoft also lists Outlook.com, a service it runs, as fixed in service release 20260925.100.

Do you really need to act?

Yes, for nearly every company with Windows desktops. The bug is not wormable and does nothing without a user opening a file. But removing the warning layer is exactly what phishing crews need, and Windows Shell keeps being a target. Tenable's Satnam Narang told CSO Online this is the third Windows Shell flaw exploited in the wild in 2026, after CVE-2026-21510, which has been linked to APT28, and CVE-2026-32202, which fixed an incomplete patch for it. He told Help Net Security it is unclear whether this one is another follow-up fix or tied to APT28.

User endpoints: patch this week. Start with people who routinely open outside files, including developers, who download archives and tools all day.
Remote Desktop and VDI hosts: treat them like desktops.
Headless servers nobody browses or opens mail on: normal cycle.
Outlook.com: fixed server-side by Microsoft. The Windows machines your users open mail on still need the OS update.

Microsoft lists no workarounds or mitigations, so the update is the fix.

What to do now

Push the October 13 cumulative update to every Windows endpoint and reboot. Check compliance in Intune, WSUS or Configuration Manager.
Spot-check builds: Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select CurrentBuild, UBR should show, for example, 26100 and 9711 or higher on Windows 11 24H2.
As defense in depth, enable the ASR rules "Block executable content from email client and webmail" (be9ba2d9-53ea-4cdc-84e5-9b1eeee46550) and "Block JavaScript or VBScript from launching downloaded executable content" (d3e037e1-3eb8-44c8-a917-57927947596d), for example with Add-MpPreference -AttackSurfaceReductionRules_Ids -AttackSurfaceReductionRules_Actions AuditMode, then switch to block.
At the mail gateway, quarantine attachment types your business rarely needs, such as shortcuts, disk images and scripts.

How to tell if you were hit

No indicators have been published. Hunt in EDR for the usual MOTW-bypass delivery chain: explorer.exe or Outlook launching wscript, cscript, mshta, powershell or cmd right after a user opened an attachment, a chat download or an extracted archive, followed by network connections or new persistence. Defender ASR audit events (AsrExecutableEmailContentAudited, AsrScriptExecutableDownloadAudited) help if the rules were already on. Ask users about any file that "opened without the usual warning". Treat endpoints with such activity before patching as compromised, and reimage them.

Timeline

Feb 10, 2026 — CISA adds an earlier Windows Shell flaw, CVE-2026-21510, to KEV.
Apr 28, 2026 — CISA adds CVE-2026-32202, the follow-up fix for CVE-2026-21510, to KEV.
Oct 13, 2026 — Microsoft releases fixes and marks CVE-2026-96951 as exploited. CISA adds it to KEV.
Oct 16, 2026 — CISA's remediation deadline for federal agencies.

Sources

Check exposure: Podman CVE-2026-94603: Images Can Disable the Sandbox

erroneo.us Security Desk — Tue, 13 Oct 2026 00:00:00 -0700

Verdict: Check exposure. If you run third-party images with rootful Podman, upgrade to 5.8.8 or 6.1.3 now, because an image can switch off the sandbox you asked for; rootless Podman and trusted-image-only hosts can patch on a normal cycle.

Who must act: Teams that run images they did not build with rootful Podman (sudo podman run, systemd/Quadlet units as root, CI runners), especially images pulled from public registries or supplied by pull requests.
Who can relax: Rootless Podman users, since checkpoint/restore is not supported rootless, and hosts that only run vetted images from registries you control.

Check versions on every host and runner: podman --version and sudo podman --version.
Upgrade to Podman 5.8.8 or 6.1.3, or your distribution's patched package (dnf update podman / apt-get install --only-upgrade podman), once available.
Until patched, do not run untrusted images with rootful Podman; use rootless Podman for third-party images.
Reject images that carry the io.podman.annotations.checkpoint.runtime.name annotation in admission scripts or CI before running them.
Review CI pipelines that run sudo podman run against images from pull requests or public registries.

What happened

Since version 4.4.0, Podman has been able to pull container checkpoints from an OCI registry and start them with podman run. A checkpoint carries a complete description of how its container is created, including the sandbox. According to the Podman advisory, when podman run sees an image with the annotation io.podman.annotations.checkpoint.runtime.name, it treats the image as a checkpoint. It then "silently ignore[s] all user input regarding how the container should be created." In the advisory's example, podman run --cap-drop=ALL on such an image ignores the flag and applies whatever capabilities the image specifies, which could be all of them.

Any image author can set that annotation. A malicious image can therefore switch off the isolation the operator asked for. The maintainers concluded that images and checkpoints cannot safely share podman run, and they removed the feature by reverting the commit that added it. Fixed releases 5.8.8 and 6.1.3 shipped on September 29, 2026. CVE-2026-94603 was published on October 13. The advisory credits ADA Logics, which found the bug using Anthropic's Claude models.

Who is affected

Podman 4.4.0 through 5.8.7 and 6.0.0 through 6.1.2 are affected when run as root. The advisory states that rootless containers are not affected, because rootless Podman does not support checkpoint/restore. That narrows real exposure to rootful use: sudo podman run, root systemd and Quadlet units, and CI runners that use rootful Podman for speed or device access.

Distribution packaging lags upstream. Red Hat rates the issue Important. Its security data lists Podman in RHEL 8, 9 and 10, OpenShift and Podman Desktop as affected with no fix yet as of October 21, 2026. Fixes have shipped for Red Hat Hardened Images (podman 6.1.3, RHSA-2026:74861) and Quay 3.12 (RHSA-2026:79546). The Amazon Linux security center lists Amazon Linux 2023 buildah as not affected. Check your distribution's package changelog for the revert, not just the upstream version number.

Do you really need to act?

The score depends on who you ask. The CVE record from GitHub's CNA scores it CVSS 3.1 10.0. Red Hat and Amazon score it 8.6, with a local attack vector and user interaction required. The lower score fits reality better: nothing happens until someone runs the attacker's image. NVD had not analyzed it as of October 21, 2026. CISA's ADP enrichment records exploitation as "none", and the CVE is not in KEV.

Running other people's images is routine, though: base images, tools from public registries, images built from pull requests. If any of that happens under rootful Podman, the sandbox flags in your scripts are not guaranteed to apply, and the image can ask for every capability. Red Hat notes that "Exploitation requires an operator or automated workflow to launch an untrusted image," so hosts that run only vetted images from your own registry are at lower risk.

What to do now

Inventory versions with podman --version and sudo podman --version on developer machines, servers and CI runners.
Upgrade to 5.8.8 or 6.1.3, or your distribution's patched build (dnf update podman, apt-get install --only-upgrade podman) once it is published.
Until then, run third-party images rootless. If root is unavoidable, check the image annotation before running it.
Add a pre-run check to CI or deployment scripts that rejects any image whose annotations include io.podman.annotations.checkpoint.runtime.name. Podman cannot do this automatically, according to the advisory.

How to tell if you were hit

Check images already pulled into root storage with sudo podman image inspect --format '{{json .Annotations}}' IMAGE and look for the checkpoint annotation. For running rootful containers, compare sudo podman inspect --format '{{.EffectiveCaps}}' CONTAINER with the capabilities you requested. A container that was asked to drop everything but holds a full capability set deserves investigation. Review CI logs and Quadlet units for rootful runs of external images, and treat any host that ran an annotated image as root as potentially compromised.

Timeline

Sep 29, 2026 — Podman 5.8.8 and 6.1.3 ship, removing checkpoint images from podman run.
Oct 13, 2026 — CVE-2026-94603 is published with a CNA score of CVSS 3.1 10.0, and CISA's ADP records no known exploitation.
Oct 15, 2026 — The advisory is added to the GitHub Advisory Database as GHSA-2cvf-wqm6-wr9g.

Sources

Most can relax: SlugFest: npm Trusted Publishing Repo-Name Hijack

erroneo.us Security Desk — Tue, 13 Oct 2026 00:00:00 -0700

Verdict: Most can relax. The hole was closed on npm's side on October 2, 2026 and no abuse has been reported, so most teams have nothing to patch; maintainers should still spend five minutes auditing trusted publisher bindings and recent publishes.

Who must act: npm package maintainers who created trusted publisher configurations that never completed a publish, renamed, transferred or deleted a bound repository or GitHub owner, or publish from GitHub Actions issue_comment workflows.
Who can relax: Package consumers and maintainers whose trusted publisher bindings have already published successfully from a repository they still control; npm binds those to the repository's immutable identity.

Run npm trust list (npm 11.15.0 or later) for each package you maintain and confirm every bound repository slug still belongs to you.
Delete and re-create bindings after any repository or owner rename, transfer or deletion; remove a binding before deleting its repository.
Publish once from a newly created binding within 48 hours so it is validated against the repository's immutable identity, or it will expire.
Move any publish workflow triggered by issue_comment to push, release or workflow_dispatch.
Review npm publish history and alerts for versions you did not release, especially on packages whose bindings were never used before October 2, 2026.

What happened

npm trusted publishing lets a CI workflow publish a package with a short-lived OIDC token instead of a stored npm token. On October 13, 2026, Bloom Security published SlugFest, research showing how npm decided which repository was trusted. Until a binding's first successful publish, npm matched on the repository slug (owner/repo) and workflow filename. It ignored the permanent repository_id and repository_owner_id claims that GitHub puts in the token. If a maintainer renamed, transferred or deleted the bound repository or owner, anyone could create a repository at the freed slug, add a workflow with the same filename and id-token: write, and exchange the resulting token for "a valid, time-limited publish token for a package they do not own." No credentials had to be stolen. Bloom says the same issue affected npm's GitLab trusted publishing.

Bloom counted more than 1,500 vulnerable packages with over 10 million total downloads. It reported the flaw through GitHub's HackerOne program on June 6, 2026. GitHub fixed it about four months later in a changelog entry dated October 2: unvalidated trusted publishing configurations now expire 48 hours after creation, and a configuration "becomes validated and exempt from expiry after its first successful publish." The same change makes npm reject trusted publishing tokens minted by GitHub Actions issue_comment events, alongside the existing pull_request_target block. No CVE was assigned.

Who is affected

The precondition was narrow: a trusted publisher binding that had never been used to publish, pointing at a slug someone else could claim. That covers bindings set up "for later," or set up before a repository move, and repositories that were deleted or renamed afterwards. Bloom withheld its list of affected packages because the pattern is still common. Package consumers were exposed only if an attacker actually published a version that way. Neither Bloom nor GitHub has reported that happening as of October 21, 2026. Bloom does say it blocked customers' AI coding agents that tried to download some of the vulnerable packages, a reminder that agents that auto-install the latest versions would pick up a hijacked release quickly.

Do you really need to act?

Consumers: no. The fix is on the registry side, and there is nothing to upgrade. Maintainers: a short audit is worthwhile. npm's documentation now says a new configuration "must complete its first successful publish within 2 days," after which it is bound "to the repository's immutable identity." Bindings that already published were bound that way before the fix, so the gap is closed for them. What remains is housekeeping. Expired configurations stay visible but no longer authorize publishing, so recreate any you still need. Any release workflow triggered by issue_comment will now fail and needs a different trigger.

What to do now

Update npm to 11.15.0 or later and run npm trust list for each package you maintain (see npm trust).
For each binding, confirm the slug still resolves to your repository: gh api repos// --jq '.id,.owner.login'.
Remove stale bindings with npm trust revoke --id=, and re-create them after any rename or transfer. Revoke a binding before deleting its repository.
After creating a binding, publish within 48 hours so it validates.
Move publish jobs off issue_comment to push, release or workflow_dispatch.

How to tell if you were hit

Compare the registry's publish history, npm view time --json, against your own release runs. A version you did not ship from your repository is the signal. Pay particular attention to packages whose trusted publisher binding existed for weeks without a publish before October 2, 2026, and to bindings whose slug now points to a repository with an ID you do not recognize. If you find an unexplained version, deprecate it, contact npm support and revoke the binding. The Hacker News summarizes the same maintainer checks.

Timeline

Jun 6, 2026 — Bloom Security reports the flaw to GitHub via HackerOne.
Jun 9, 2026 — The report is triaged and validated.
Jul 8, 2026 — GitHub's last response before the fix, per Bloom.
Oct 2, 2026 — GitHub ships 48-hour expiry for unvalidated configurations and blocks issue_comment tokens.
Oct 13, 2026 — Bloom publishes SlugFest, followed by press coverage.

Sources

Security digest: October 13, 2026

erroneo.us Security Desk — Tue, 13 Oct 2026 00:00:00 -0700

5 editorial briefs, 2 known exploited (cisa kev) additions and 3 critical advisories.

Known exploited (CISA KEV)

CVE-2026-96951 Microsoft Windows: Microsoft Windows Command Injection Vulnerability (due 2026-10-16)
CVE-2026-104935 Ivanti Connect Secure: Ivanti Connect Secure Authentication Bypass by Spoofing Vulnerability (due 2026-10-16)

Critical advisories

Security digest: October 9, 2026

erroneo.us Security Desk — Fri, 09 Oct 2026 00:00:00 -0700

4 critical advisories.

Critical advisories

Patch this week: Go October 2026 Security Releases: 16 Stdlib Fixes

erroneo.us Security Desk — Thu, 08 Oct 2026 00:00:00 -0700

Verdict: Patch this week. Rebuild and redeploy Go services with Go 1.27.3 or 1.26.10 this week, starting with internet-facing HTTP/2 servers and reverse proxies; none of these bugs is known to be exploited.

Who must act: Teams shipping Go binaries that serve HTTP/2 or HTTP/1 to untrusted clients, Go reverse proxies, apps rendering JavaScript through html/template, and anyone verifying TLS chains with crypto/x509 on systems with stale trust stores.
Who can relax: Go code that never serves network traffic or renders templates can take the update on its next release; Windows-only Root.Mkdir and toolchain checksum issues need a malicious project or proxy you chose to use.

Check the toolchain and the binaries you ship: go version, and go version -m ./yourbinary for deployed builds.
Move builds to Go 1.27.3 or 1.26.10 (for example go get toolchain@go1.27.3, or update the golang base image in your Dockerfile), then rebuild and redeploy every service.
If you use golang.org/x/net/http2 directly, run go get golang.org/x/net@v0.60.0 && go mod tidy.
Run govulncheck ./... to see which of the 16 issues your code actually reaches.
Prioritize internet-facing HTTP/2 servers, httputil.ReverseProxy deployments and services that render user-influenced JavaScript through html/template.

What happened

Go shipped two security releases in October 2026. On October 8, Go 1.27.2 and 1.26.9 fixed 15 vulnerabilities in the standard library and the go command. Most are in net/http. On October 19, Go 1.27.3 and 1.26.10 followed as an urgent-track fix to crypto/x509 (CVE-2026-111943). That release blocks "a small set of intermediate certificates due to specific security concerns around their operation." The Go team "highly recommend[s] immediately upgrading." It did not name the certificate authority as of October 21, 2026.

The October 8 fixes fall into four groups:

HTTP/2 denial of service: a client can crash a server by racing the HPACK encoder against SETTINGS_HEADER_TABLE_SIZE changes (CVE-2026-97032). Other bugs let a client exhaust memory with a "Trailer" header declaring many fields, bypassing MaxHeaderBytes (CVE-2026-78659), burn CPU with repeated SETTINGS_INITIAL_WINDOW_SIZE frames (CVE-2026-78669), or get flow control refunded twice (CVE-2026-78663). RyotaK of GMO Flatt Security is credited with the first two.
Smuggling and desync: the HTTP/2 transport forwarded malformed framing headers that can enable response smuggling through a reverse proxy (CVE-2026-78660). HTTP/1 CONNECT handling could desynchronize pooled client connections (CVE-2026-56866) or keep serving HTTP on a tunneled server connection (CVE-2026-94439).
Other resource limits and escaping: Range-header CPU exhaustion in FileServer/ServeContent (CVE-2026-78667), a multipart memory-limit bypass (CVE-2026-94440), ECH memory amplification in crypto/tls (CVE-2026-97031), and two html/template JavaScript escaping errors (CVE-2026-94448, CVE-2026-97030).
Toolchain and OS: two cmd/go checksum bypasses that require a malicious project plus a malicious module proxy (CVE-2026-94444, CVE-2026-94447), and a Windows os.Root junction escape (CVE-2026-56857).

Who is affected

Any program built with Go before 1.26.9, or with 1.27.0 or 1.27.1, carries the October 8 bugs. Programs built before 1.26.10, or with any 1.27 release before 1.27.3, lack the certificate denylist. The release history lists the affected packages. Go statically links the standard library into every binary, so upgrading the toolchain on your laptop changes nothing in production until you rebuild and redeploy. The HTTP/2 fixes also landed in golang.org/x/net v0.60.0 for code that imports x/net/http2 directly, according to the Go vulnerability database.

Do you really need to act?

For internet-facing Go HTTP servers, yes, this week. The HPACK race and the Trailer memory bug need no authentication. Default net/http servers negotiate HTTP/2 over TLS automatically, so an exposed service is reachable unless you disabled HTTP/2. CISA's ADP enrichment on the CVE record scores CVE-2026-97032 at CVSS 3.1 7.5 (availability only). None of these CVEs is in CISA KEV, and no exploitation had been reported as of October 21, 2026.

The smuggling bugs matter most if you run Go reverse proxies in front of HTTP/1 backends. The html/template fixes matter if templates render untrusted data inside JavaScript template literals. On the x509 change, the Go team says most platforms use system roots. The denylist covers "narrower cases" where system trust stores may not be updated, per GO-2026-6809 and Go issue 82345. The toolchain and Windows os.Root bugs are low-priority for most teams.

What to do now

See what you build and ship: go version for the toolchain and go version -m ./yourbinary for deployed artifacts.
Pin the fixed toolchain, for example with go get toolchain@go1.27.3 in each module, or bump the golang base image tag in Dockerfiles and CI.
Update golang.org/x/net if you import it: go get golang.org/x/net@v0.60.0 && go mod tidy.
Rebuild and redeploy every service and container, starting with public HTTP/2 endpoints and reverse proxies.
Run govulncheck ./... to confirm which issues your code reaches, and use the result for prioritization, not as a reason to skip the rebuild.

How to tell if you were hit

Most of these bugs cause outages, not intrusions. Look for HTTP/2 server crashes with stack traces in the HPACK encoder or concurrent map writes, sudden memory growth on requests with large Trailer headers, and CPU spikes tied to clients sending floods of SETTINGS frames or Range headers with hundreds of ranges. For smuggling, compare proxy and backend access logs for responses that do not match their requests. To find unpatched builds, run govulncheck -mode=binary across your release artifacts.

Timeline

Oct 8, 2026 — Go 1.27.2 and 1.26.9 are released with 15 security fixes, and the CVE records are published.
Oct 19, 2026 — Go 1.27.3 and 1.26.10 are released with the crypto/x509 intermediate-certificate denylist (CVE-2026-111943).
Oct 21, 2026 — GO-2026-6809 is published in the Go vulnerability database.

Sources

Check exposure: ProFTPD mod_copy CVE-2015-3306: 2015 Bug Added to KEV

erroneo.us Security Desk — Thu, 08 Oct 2026 00:00:00 -0700

Verdict: Check exposure. Nearly everyone fixed this a decade ago; the real job is finding any ProFTPD 1.3.5-era build with mod_copy still answering on port 21, usually inside old appliances, and replacing or removing it.

Who must act: Operators of internet-facing FTP servers, NAS boxes, hosting servers or embedded appliances running ProFTPD 1.3.5 or older builds with mod_copy loaded and no 2015 patch.
Who can relax: Anyone on ProFTPD 1.3.5a or later, on a distribution package patched in 2015, or running a build without mod_copy, which upstream does not compile by default.

Scan your external address ranges for FTP on port 21 and flag any banner reporting ProFTPD 1.3.5 or older.
On each ProFTPD host, run proftpd -v and proftpd -l, and grep the configuration for LoadModule mod_copy.c, to see the version and whether mod_copy is present.
Upgrade to a current ProFTPD release or a distro package with the 2015 fix, and replace appliances whose firmware still ships 1.3.5.
If you do not need server-side copy, stop loading mod_copy; on 1.3.6rc1 and later you can also set CopyEngine off.
Close FTP to the internet where it is not required, or move users to SFTP, as the joint advisory recommends disabling unused file-sharing services.

What happened

On October 8, 2026, the FBI, CISA, NSA and agencies from the UK, Australia, Canada, Japan, New Zealand and Spain published joint advisory AA26-281A. It covers actors enabled by Integrity Technology Group, a China-based company. CISA says the actors it enables use techniques consistent with Flax Typhoon, Ethereal Panda and Red Juliett. Appendix B lists eight "successfully exploited" CVEs, drawn from penetration-testing scripts in a tool called MicroScan. The actors have used it since as early as 2017. Five of the eight were added to the KEV catalog that day with an October 11 federal deadline. One is CVE-2015-3306 in ProFTPD. The others are ONLYOFFICE Docs CVE-2021-3199, Strapi CVE-2023-22894, Apache Struts CVE-2016-3081 and ISC BIND CVE-2015-5477.

The bug itself is eleven years old. In April 2015, Vadim Melihow reported to ProFTPD (bug 4169) that mod_copy accepted SITE CPFR and SITE CPTO from unauthenticated clients. His example copied /etc/passwd to /tmp. A second example got PHP code into the server log through a failed command, then copied /proc/self/fd/3 into /var/www/test.php. That turns a file-copy bug into remote code execution on servers that also host a website. The CVE record cites public exploits, including a Metasploit module. CISA's enrichment scores it CVSS 3.1 10.0, and NVD gives 10.0 on CVSS 2.

Who is affected

ProFTPD 1.3.5 with mod_copy loaded. Upstream fixed it in 1.3.5a and 1.3.6rc1 in 2015 and added a CopyEngine switch. The module documentation says mod_copy "is not compiled by default," but distributions shipped it. Debian's DSA-3263-1 fixed both wheezy (1.3.4a) and jessie (1.3.5) packages. Current upstream is 1.3.9d. Today the exposed population is whatever never got updated: old NAS and storage appliances, end-of-life Linux servers, hosting boxes and embedded devices with frozen firmware.

Do you really need to act?

Only if you still have such a box, and you may not know you do. The KEV listing is not evidence of a new campaign. VulnCheck notes that the first exploitation evidence for this CVE in its KEV is the report date itself, and quotes the advisory's warning that many indicators are old, "some dating back to 2016." What the advisory does show is that a well-resourced, state-linked ecosystem keeps this exploit in its scanning kit. It says these actors focus their scans on ports 21 (FTP), 22, 53, 80, 443 and 1080. Anything still vulnerable and reachable will be found.

So the verdict is check exposure, not panic. If a scan of your ranges turns up nothing older than ProFTPD 1.3.5a, you are done. If it finds a 1.3.5 banner, fix it today and investigate the host. US federal agencies had until October 11 to patch or stop using affected products, as The Hacker News notes.

What to do now

Scan external ranges for port 21 and collect banners, for example nmap -sV -p21 . Flag anything reporting ProFTPD 1.3.5 or older.
On each ProFTPD host, run proftpd -v for the version and proftpd -l for compiled-in modules. Also run grep -ri 'mod_copy' /etc/proftpd* to find DSO loads.
Upgrade to a current release or a distro package carrying the 2015 fix. For appliances, apply vendor firmware or retire the device.
Stop loading mod_copy if you do not use server-side copy. On 1.3.6rc1 and later, CopyEngine off disables it at runtime.
Follow the advisory's guidance to disable unused file-sharing services. Remove FTP from the internet or replace it with SFTP.

How to tell if you were hit

Search FTP command logs (an ExtendedLog, if configured) or packet captures for SITE CPFR and SITE CPTO, especially before any successful USER/PASS. On hosts that also serve web content, look for unexpected .php or script files in document roots, and for copies of /etc/passwd, configs or keys in FTP-served or world-readable directories. Check the advisory's downloadable IOC set against firewall and proxy logs. If a vulnerable build was internet-facing, rebuild the host rather than cleaning it, and rotate any credentials stored on it.

Timeline

Apr 7, 2015 — Vadim Melihow's report is filed as ProFTPD bug 4169, and a fix is merged the same day.
May 19, 2015 — Debian publishes DSA-3263-1.
May 28, 2015 — ProFTPD marks the bug resolved in 1.3.5a and 1.3.6rc1.
Oct 8, 2026 — Joint advisory AA26-281A is published, and CISA adds CVE-2015-3306 and four other old CVEs to KEV.
Oct 11, 2026 — CISA's remediation deadline for federal agencies.

Sources

Security digest: October 8, 2026

erroneo.us Security Desk — Thu, 08 Oct 2026 00:00:00 -0700

2 editorial briefs, 5 known exploited (cisa kev) additions and 7 critical advisories.

Known exploited (CISA KEV)

CVE-2023-22894 Strapi Strapi: Strapi Cleartext Storage of Sensitive Information Vulnerability (due 2026-10-11)
CVE-2021-3199 ONLYOFFICE Docs: ONLYOFFICE Docs Server Path Traversal Vulnerability (due 2026-10-11)
CVE-2016-3081 Apache Struts: Apache Struts Command Injection Vulnerability (due 2026-10-11)
CVE-2015-5477 ISC BIND: ISC BIND Data Processing Errors Vulnerability (due 2026-10-11)
CVE-2015-3306 ProFTPD ProFTPD: ProFTPD Improper Access Control Vulnerability (due 2026-10-11)

Critical advisories

Patch this week: Argo CD: Repo-Server RCE and AppProject Bypass (Oct 2026)

erroneo.us Security Desk — Wed, 07 Oct 2026 00:00:00 -0700

Verdict: Patch this week. Upgrade Argo CD to a patched 3.3, 3.4 or 3.5 release this week, and today on shared instances where people you do not fully trust can push to tracked repos or merely view an Application.

Who must act: Teams running Argo CD 2.x or 3.x, most urgently multi-tenant installs where developers, tenants or CI bots can push to tracked Git repos, hold Application get, or manage repositories.
Who can relax: Single-team installs where only platform admins can push to tracked repos and use the Argo CD API carry less risk, but should still upgrade on a normal short cycle.

Check the running version on every Argo CD instance and upgrade to 3.3.15, 3.4.10, 3.5.4 or 3.6.0-rc2; move 2.x and 3.0-3.2 to a supported line.
Until upgraded, set jsonnet.enable to "false" in argocd-cm if you do not use Jsonnet, and remove --enable-helm from kustomize.buildOptions if you do not render Helm through Kustomize.
Restrict Git write access to repos backing restricted AppProjects, and limit who can delete Applications, create or update repositories, and call the API with Application get.
Rotate the Git, Helm and OCI credentials the repo-server holds if untrusted users had any of those paths.
After upgrading, review the application-controller's Kubernetes permissions so a bypass cannot reach cluster-wide RBAC.

What happened

On October 6, 2026, the Argo CD project shipped 3.3.15, 3.4.10, 3.5.4 and 3.6.0-rc2. On October 7 it published eight security advisories, four of them critical at CVSS 3.1 9.9, as the release notes list. Each critical bug needs only low privileges, and each lets a tenant reach well past what Argo CD is supposed to allow them:

CVE-2026-77459, AppProject bypass (GHSA-fmxq-cgp8-87wp). PreDelete and PostDelete hooks skip the AppProject destination and resource checks. When the Application is deleted, Argo CD creates them with the application-controller's credentials. Anyone who can push to the source repo can, for example, get a ClusterRoleBinding or an object in a forbidden namespace created.
CVE-2026-113708, Kustomize remote ref (GHSA-9v9p-x54c-58gc). A remote base ref beginning with - is parsed as a git fetch option. --upload-pack with a file:// URL then runs a command in argocd-repo-server.
CVE-2026-113709, Kustomize Helm config home (GHSA-fw5c-w8rc-j7fx). Where --enable-helm is set, helmGlobals.configHome can load a Helm downloader plugin from the repo, which then runs in the repo-server.
CVE-2026-113672, Jsonnet import file read (GHSA-m3vr-7329-44ww). import and importstr can read absolute paths such as /proc/self/environ, the service-account token, and repository credentials.

A fifth, high-severity bug, CVE-2026-55797 (GHSA-j6cw-g6p4-7hch, 8.8), lets anyone who can set a proxy on an SSH repository inject shell commands into the repo-server.

Who is affected

Every supported release before the fixed builds is affected. The bugs go back a long way: Jsonnet reads to v0.9.0, the Helm config home to v2.1.0, Kustomize refs to v2.7.0, and PostDelete hooks to v2.10.0. The advisories state that "Argo CD 2.x and 3.0 through 3.2 are out of support and will not receive a patch." Those versions need an upgrade to 3.3 or later, not a hotfix.

Do you really need to act?

If your Argo CD is shared, yes. In a typical install the repo-server holds every Git, Helm and OCI credential, and the controller has broad cluster rights. Command execution in one, or object creation through the other, undoes your tenant isolation. The bar is low. The three repo-server bugs can be triggered by committing a file to a tracked repo. They can also be triggered by uploading it through POST /api/v1/applications/manifestsWithFiles, which, per the advisories, needs only Application get and no sync rights or Git access. Blocking repo-server egress does not stop the Kustomize ref bug, because a file:// remote never leaves the pod.

No exploitation has been reported. CISA's enrichment records "none" for CVE-2026-77459 on the CVE record, and none of these is in KEV. Single-team installs where only admins push and use the API face mostly insider risk.

What to do now

Check versions with argocd version, or kubectl -n argocd get deploy argocd-repo-server -o jsonpath='{.spec.template.spec.containers[0].image}'. Then upgrade to 3.3.15, 3.4.10 or 3.5.4.
Until then, apply the advisories' workarounds. Set jsonnet.enable: "false" in argocd-cm if you don't use Jsonnet, and drop --enable-helm from kustomize.buildOptions; both are complete workarounds for their bug. For the Kustomize ref bug, the only stopgap is pinning Applications to Kustomize older than 5.0, and the AppProject hook bypass has no configuration fix.
Tighten RBAC: who can push to repos behind restricted AppProjects, who can delete Applications, who can add or edit repositories, and who holds Application get.
If untrusted users had any of these paths, rotate the credentials the repo-server can read.

How to tell if you were hit

Grep tracked repositories for kustomizations that use helmGlobals/configHome or remote refs whose ref/version starts with - or uses file://. Also grep for .jsonnet files that import absolute or ../ paths. Search for resources annotated argocd.argoproj.io/hook: PreDelete or PostDelete that target namespaces or kinds the project forbids, and list recent ClusterRoleBinding objects (kubectl get clusterrolebindings --sort-by=.metadata.creationTimestamp). Review repository and credential-template Secrets for unexpected proxy values, and check API server logs for manifestsWithFiles calls from unexpected users.

Timeline

Oct 6, 2026 — Argo CD 3.3.15, 3.4.10, 3.5.4 and 3.6.0-rc2 are released.
Oct 7, 2026 — The project publishes eight advisories, four of them critical.
Oct 13, 2026 — The CVE-2026-77459 record is published, and NVD lists it the same day.
Oct 15, 2026 — GHSA-fmxq-cgp8-87wp enters the GitHub Advisory Database.
Oct 20, 2026 — CVE records for CVE-2026-113708, -113709 and -113672 are published.

Sources

Check exposure: GhostAction: Fake Security Workflows Steal GitHub Secrets

erroneo.us Security Desk — Wed, 07 Oct 2026 00:00:00 -0700

Verdict: Check exposure. If any repository you own or contribute to gained a security-audit.yml or github_actions_security.yml workflow you did not write, treat its Actions secrets, every credential ever committed to it, and the pushing account as compromised.

Who must act: Maintainers and organizations whose repositories, including forks and mirrors, received an injected 'Security Audit' or 'Github Actions Security' workflow since August 31, 2026, and anyone whose GitHub token or password may sit in infostealer logs.
Who can relax: Repositories with no such workflow in any branch, and organizations that already require approval for workflow runs and block direct pushes to .github/workflows; GitHub has been stopping the October payload from running since October 9.

Search every branch of your repositories and forks for security-audit.yml, github_actions_security.yml and security-check.yml, and for the string 193.32.204.199.
If found, revoke the GitHub credential that pushed it (PATs, OAuth grants, SSH keys, sessions) and re-enroll the account with phishing-resistant MFA.
Rotate every Actions secret named in the workflow and every credential ever committed to the repository, including ones deleted from history.
Delete the workflow from all branches, revert the commit, and check forks before enabling Actions on them.
Require approval for workflow runs, protect .github/workflows with rulesets or CODEOWNERS, and turn on secret scanning push protection.

What happened

GhostAction uses stolen maintainer credentials to commit a workflow that looks like a security check but exists to send secrets to the attacker. GitGuardian first documented it in September 2025. In its October 7, 2026 report, GitGuardian says "GhostAction never really stopped." Between August 31 and September 30, 2026, a github_actions_security.yml workflow was pushed to 772 public repositories belonging to 373 users and organizations, naming 2,577 secrets. Most of those runs were held for approval. Of 3,669 runs GitGuardian collected, 336 completed and exfiltrated 26 secrets from 13 repositories.

The October wave was far larger and more capable. Socket and StepSecurity traced an October 8 burst through two compromised maintainer accounts. kitao, the author of Pyxel, pushed to 27 repositories. henrywoo pushed to 318 repositories, including 279 forks, in 16 minutes, ending with Uber's uber/athenadriver. Commits used the victims' real identities, went straight to the default branch and were unsigned. By its October 13 update, GitGuardian counted more than 30,000 repositories across about 3,000 users and organizations, about 1,900 compromised user accounts and 3,174 targeted secrets. It reports that GitHub began preventing the workflow from running on October 9, so waves on October 10 and 12 extracted nothing. GitHub has not published a statement as of October 21, 2026.

Who is affected

The new security-audit.yml runs on any push or manual dispatch and checks out full history with fetch-depth: 0. It sends the repository's named Actions secrets, then greps the working tree and git log -p --all for 13 credential patterns. Those cover AWS keys and session tokens, Anthropic, OpenAI and OpenRouter keys, GitHub and GitLab PATs, and Google, Slack and SendGrid keys. Everything goes in one plain-HTTP POST to 193.32.204.199. Scanning history means credentials committed years ago and later deleted were exposed. GitGuardian reads that as aimed at private repositories, where committed secrets are common. Forks carry the file too, and enabling Actions on a fork or syncing it can run the harvester.

Do you really need to act?

Check, yes. Panic, no. The question is whether the workflow landed in anything you own, fork or mirror, and whether it ran. StepSecurity found that a run on uber/athenadriver reached the attacker's server four seconds after starting, while runs held at action_required by an approval gate never executed. Researchers had seen no malicious package releases using the stolen PyPI, crates.io or other publishing credentials as of October 9. That is not proof the tokens are safe. GitGuardian also stresses that some victims appeared in earlier waves, which suggests secrets were never rotated, and that a compromised account "must be found and revoked too, or someone else will use it again."

What to do now

Find the workflow: gh search code '193.32.204.199' --owner and gh search code 'AKIA_CTX_START' --owner . Locally, run git log --all --name-only -- .github/workflows/ | grep -E 'security-audit|github_actions_security|security-check'.
Revoke the account's credentials: PATs, OAuth apps, SSH keys and active sessions. Then reset the password with phishing-resistant MFA, assuming an infostealer.
Rotate every secret the workflow named and every credential found by git log -p --all. Review registry release history and CloudTrail.
Delete the workflow from all branches and revert the commit. Audit forks before enabling Actions.
Require approval for workflow runs, protect .github/workflows/, restrict GITHUB_TOKEN permissions per GitHub's secure-use guidance, and enable push protection.

How to tell if you were hit

A completed run of a "Security Audit" or "Github Actions Security" workflow since August 31 means the named secrets were sent. The marker ?c=monami means named secrets were found, and ?c=new means history-only results. In the organization audit log, look for maintainers adding workflow files directly to default branches. Also look for rapid unsigned commits titled "Add security audit workflow" and for workflow_dispatch on new audit workflows. Search egress telemetry for 193.32.204.199 on ports 80 and 3000, and CloudTrail for new IAM users or keys tied to any AWS key in the repository.

Timeline

Aug 31, 2026 — First 2026 burst: 143 repositories receive github_actions_security.yml.
Sep 5, 2026 — Peak day of the late-summer wave, with 294 repositories (per GitGuardian).
Oct 7, 2026 — GitGuardian publishes its report, and the October wave begins (per Socket).
Oct 8, 2026 — The kitao and henrywoo accounts push the history-mining variant, and a phased push reaches about 28,000 new repositories by Oct 9.
Oct 9, 2026 — GitHub starts preventing the workflow from running. Socket and StepSecurity publish, and press coverage begins.
Oct 15, 2026 — Reporting on GitGuardian's updated count of about 1,900 compromised accounts.

Sources

Security digest: October 7, 2026

erroneo.us Security Desk — Wed, 07 Oct 2026 00:00:00 -0700

2 editorial briefs and 12 critical advisories.

Critical advisories

Security digest: October 6, 2026

erroneo.us Security Desk — Tue, 06 Oct 2026 00:00:00 -0700

6 critical advisories.

Critical advisories

Act now: Atlassian Data Center File Read CVE-2026-21589 Exploited

erroneo.us Security Desk — Mon, 05 Oct 2026 00:00:00 -0700

Verdict: Act now. Every self-managed Atlassian Data Center product is affected, a public detection script exists and CISA confirms exploitation; patch to a fixed LTS or block traversal patterns at the edge today.

Who must act: Anyone running self-managed Jira, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Crucible or Fisheye, especially instances reachable from the internet.
Who can relax: Atlassian Cloud customers: Atlassian says Cloud is patched, found no evidence of exploitation there, and requires no customer action.

List every self-managed Atlassian instance, including test, staging and Bitbucket mirrors.
Upgrade each to a fixed version for its line (or the latest release), on every cluster node.
If you cannot patch today, take internet-facing instances off the internet, or block URLs with '..' next to /, \ or :: (including URL-encoded forms) using Atlassian's WAF regex or Tomcat RewriteValve rule.
Search access logs (URL-decoded up to twice) for '..' adjacent to /, \ or :: since early October.
If any request matched, treat files in the web application root as exposed and rotate any secrets they contain.

What happened

On October 5, 2026 Atlassian published an advisory for CVE-2026-21589, an arbitrary file access flaw in essentially its whole self-managed line. Affected products are Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo and Crowd Data Center, plus Crucible and Fisheye. An unauthenticated attacker can read specific files inside the web application root directory. Atlassian rates it Critical, CVSS 4.0 score 9.3.

There are limits. The attacker has to know the exact name and path of the target file, and the bug "does not allow attackers to enumerate or list directory contents." Atlassian warns, though, that "in some configurations, there may be sensitive files present that increase your risk." The mitigations it published all block .. sequences next to /, \ or ::, which means this is a path-traversal bug.

watchTowr published a detection script for Jira, Confluence and Bitbucket on October 6. CISA added the CVE to its Known Exploited Vulnerabilities catalog on October 15 and set a federal remediation due date of October 18.

Who is affected

Atlassian says all versions before the fixed releases are affected. The CVE record gives starting points: Bitbucket from 4.6.0, Confluence from 5.10.0, Jira Software from 7.1.0, Jira Service Management from 3.1.0, Bamboo from 7.0.1 and Crowd from 2.11.0. In practice that is any self-managed instance not patched since early October. Atlassian Cloud was patched by Atlassian, which says it found no evidence of exploitation there and that no Cloud customer action is needed.

Do you really need to act?

If you run any of these products yourself, yes. Several factors push this to the top of the list:

No authentication is required, and the products are often exposed to the internet for remote staff, customers (Jira Service Management) or CI integrations (Bitbucket, Bamboo).
Exploitation is confirmed by CISA. Its vulnrichment data in the CVE record marks exploitation as "active" with "total" technical impact.
The "needs the exact path" limitation is weaker than it sounds for software that is installed the same way everywhere. Attackers know where standard files live.
NVD records Atlassian's vector with high confidentiality impact and high subsequent-system impact. The bug reads files rather than writing them, but what it reads can unlock other systems.

Atlassian says "instances accessible to the public internet, including those with user authentication, should be restricted from external network access" until patched or mitigated. Instances reachable only on an internal network are less urgent, but still a short-fuse patch.

What to do now

Inventory every Data Center, Crucible and Fisheye instance, including staging, DR, and Bitbucket mirrors and mirror farm nodes.
Upgrade to a fixed version. Atlassian recommends the fixed LTS or later. Fixed versions are Bitbucket 9.4.26, 10.2.8 or 10.5.1; Confluence 9.2.26 or 10.2.19; Jira Software 9.12.40, 10.3.26 or 11.3.12; Jira Service Management 5.12.40, 10.3.26 or 11.3.12; Bamboo 10.2.24 or 12.1.12; Crowd 6.3.7, 7.0.3, 7.1.7 or 7.2.4; Crucible and Fisheye 4.9.15. Patch every cluster node.
If you cannot patch now, take the instance off the internet. Or apply one of Atlassian's mitigations on every node: a WAF or proxy rule using its regex (block .. adjacent to /, \ or ::, including URL-encoded forms), Tomcat's RewriteValve with the provided rewrite.config (Confluence, Jira, JSM, Bamboo, Crowd), or a urlrewrite.xml rule (Bitbucket). Test that encoded variants are actually blocked.
Restart the nodes after configuration changes, and confirm the rule fires.

How to tell if you were hit

Atlassian says it "cannot confirm if your instances have been affected" and recommends log review. URL-decode each access-log request line (up to two passes) and look for .. immediately next to /, \ or ::. Or run Atlassian's regex over the raw lines. Pay most attention to matching requests that got 200 responses. If you find any, assume the files they targeted were read, find out what those files contain, and rotate any credentials or keys among them. The watchTowr script is a quick way to confirm your own instance is no longer vulnerable once patched.

Timeline

Oct 5, 2026 — Atlassian publishes the advisory and fixed versions. The CVE record is published.
Oct 6, 2026 — watchTowr publishes a public detection script for Jira, Confluence and Bitbucket.
Oct 15, 2026 — CISA adds CVE-2026-21589 to KEV, with a federal due date of Oct 18.

Sources

Security digest: October 5, 2026

erroneo.us Security Desk — Mon, 05 Oct 2026 00:00:00 -0700

1 editorial brief and 17 critical advisories.

Critical advisories

Act now: AhsayCBS: Exploited Pre-Auth RCE Chain in Backup Server

erroneo.us Security Desk — Sun, 04 Oct 2026 00:00:00 -0700

Verdict: Act now. If you or your MSP run an AhsayCBS backup server, install the October 12 hotfix today and hunt for webshells: the chain is unauthenticated, runs as SYSTEM, is being exploited by several actors, and the August patch did not fix it.

Who must act: MSPs, system integrators and companies running AhsayCBS v7 through v10 below 10.3.4.45 or 9.15.2.70, including servers that already applied 10.3.4.0 or 9.15.2.59.
Who can relax: Organizations that do not operate an AhsayCBS server; backup customers of a provider that uses Ahsay should still get written confirmation that the provider has patched and checked for compromise.

Check the build in the AhsayCBS web console under System Settings > License > Update License (Product Version).
Apply hotfix 10.3.4.45 (v10) or 9.15.2.70 (v7-v9) from Ahsay's partner portal, then reboot the server.
Restrict the management web interface to trusted admin IPs or a VPN.
Hunt for compromise back to Oct 4, 2026: new JSP files, shells spawned by the AhsayCBS service, a fake MicrosoftEdgeUpdateSvc, and new OpenSSH installs.
If you find indicators, re-image the host from a trusted backup and rotate every credential stored on or used by the server.

What happened

AhsayCBS is the server and management console of Ahsay's backup platform. Huntress says it is used mainly by MSPs and system integrators to create users, set backup policies and run backup operations. On October 4, 2026, VulDB published two CVEs against it and noted that an exploit had been published:

CVE-2026-105133 (CVE record, CWE-287): manipulating the random argument in the API's checkSysPwd function bypasses authentication. CVSS 3.1 7.3.
CVE-2026-105134 (CVE record, CWE-78): the same argument is injected into OS commands at the Replication Receiver endpoint /rps/api/json/UpdateReceivers.do. CVSS 3.1 10.0.

Three days later the chain was in use. Huntress saw the first exploitation on October 7 at 23:20 UTC and had counted five targeted organizations by October 8. The attackers ran code as SYSTEM, set up a malicious replication receiver and dropped JSP webshells. They also installed an XMRig miner disguised as edge.exe, kept alive by a fake MicrosoftEdgeUpdateSvc service. Bitdefender's MDR team investigated three incidents involving webshells, PowerShell staged in C:\Users\Public, credential reconnaissance and an OpenSSH install via obfuscated PowerShell. It says "several different actors may be using the same exploits" and saw no encryption or exfiltration. CISA added both CVEs to KEV on October 14, with an October 17 deadline.

Who is affected

The CVE records and NVD say AhsayCBS up to 10.3.2 is affected and 10.3.4 is not. That is no longer accurate. Huntress found on October 8 that 10.3.4 is also vulnerable. On October 12, Ahsay said its earlier patches, 10.3.4.0 and 9.15.2.59, did not fully address the flaws, and released partner-only hotfixes: 10.3.4.45 for v10 and 9.15.2.70 for v7, v8 and v9. Ahsay's 10.3.4 release notes (August 5, 2026) list no security fixes at all. Treat every build below those two hotfixes as vulnerable.

Do you really need to act?

Only if an AhsayCBS server is yours or holds your data, and in that case, yes, today. The chain needs no credentials and gives SYSTEM on the machine that controls backup users, policies and operations for every customer it serves. Exploitation began within days of disclosure, more than one actor appears to be involved (CVE-2026-105133 is also in KEV), and many operators who installed 10.3.4.0 in good faith believed they were patched. Teams that only run endpoint backup clients against a provider's server have nothing to install, but they should ask the provider directly. Everyone else can ignore this one.

What to do now

Confirm the build in the web console under System Settings > License > Update License (Product Version), as Bitdefender describes.
Download and apply hotfix 10.3.4.45 (v10) or 9.15.2.70 (v7-v9) from Ahsay's partner portal, then reboot, as Ahsay instructs. Huntress verified that 10.3.4.45 "mitigates the initial entry point."
Limit the management interface to trusted IPs or a VPN. Huntress and Bitdefender both recommend this, but it is not vendor guidance and not a substitute for patching.
Hunt from October 4 onward (next section). Patching does not remove webshells or other persistence.
If you find indicators, re-image from a trusted backup, as Huntress advises, and rotate credentials the server stores or uses.

How to tell if you were hit

Look for new or changed .jsp files in the AhsayCBS web application directories, and cmd.exe or powershell.exe running as children of the AhsayCBS service. Other signs are a MicrosoftEdgeUpdateSvc service backed by edge.exe (XMRig) or msedge.exe (a modified NSSM), a Taskgmr.ps1 script, a downloaded WinRing0x64.sys driver, .cmd files in C:\Users\Public, and an OpenSSH server that was never there before. On the network, check for traffic to 38.60.252.110 (reported by both firms), xmr.kryptex.network:8029 and imagefiles-backup.oss-ap-southeast-7.aliyuncs.com. Bitdefender cautions that the reliable signal is "how the server behaves after the exploit fires," because static indicators change between actors.

Timeline

Aug 5, 2026 — AhsayCBS 10.3.4 is released.
Oct 4, 2026 — CVE-2026-105133 and CVE-2026-105134 are published, with a public exploit noted.
Oct 7, 2026 — Huntress sees the first exploitation at 23:20 UTC.
Oct 8, 2026 — Huntress publishes its findings, then confirms that 10.3.4 is also affected.
Oct 12, 2026 — Ahsay says the earlier patches were incomplete and releases hotfixes 10.3.4.45 and 9.15.2.70.
Oct 14, 2026 — CISA adds both CVEs to KEV.
Oct 15, 2026 — Bitdefender publishes its advisory, based on three incidents.

Sources

Security digest: October 4, 2026

erroneo.us Security Desk — Sun, 04 Oct 2026 00:00:00 -0700

1 editorial brief and 1 known exploited (cisa kev) addition.

Known exploited (CISA KEV)

CVE-2026-88779 Citrix NetScaler: Citrix NetScaler Improper Restriction of Operations within the Bounds of a Memory Buffer Vulnerability (due 2026-10-07)

Security digest: October 2, 2026

erroneo.us Security Desk — Fri, 02 Oct 2026 00:00:00 -0700

2 known exploited (cisa kev) additions and 5 critical advisories.

Known exploited (CISA KEV)

CVE-2026-102490 Zammad GmbH Zammad: Zammad GmbH Zammad Improper Privilege Management Vulnerability (due 2026-10-05)
CVE-2026-102489 Zammad GmbH Zammad: Zammad GmbH Zammad Session Fixation Vulnerability (due 2026-10-05)

Critical advisories

Act now: FortiMail CVE-2026-104286: Exploited Pre-Auth File Write

erroneo.us Security Desk — Thu, 01 Oct 2026 00:00:00 -0700

Verdict: Act now. If you run a self-managed FortiMail, upgrade today and check Fortinet's indicators; this is an unauthenticated file-write zero-day on an internet-facing mail gateway.

Who must act: Anyone running FortiMail 7.2, 7.4, 7.6 or 8.0 as an appliance or VM, most urgently where the webmail or IBE interface is reachable from the internet.
Who can relax: FortiMail Cloud customers, whom Fortinet patched on Oct 5, 2026, and organizations that do not run FortiMail.

List every FortiMail appliance and VM and check its firmware with get system status.
Upgrade to 8.0.2, 7.6.7 or 7.4.9 or later; move 7.2 systems to 7.4.9 or later.
If you cannot upgrade today, disable the IBE service (config system encryption ibe, set status disable, end) or remove internet access to the webmail interface.
With a WAF in front of FortiMail, block POST requests to /ibe that contain '../' until patched.
Hunt for Fortinet's indicators before and after upgrading, because upgrading does not remove anything an attacker already planted.
If you find indicators, treat the appliance as compromised: preserve logs, engage Fortinet support, rebuild, and rotate admin passwords and any credentials stored on the device.

What happened

On October 1, 2026, Fortinet published FG-IR-26-175 for CVE-2026-104286, a critical flaw in FortiMail, its email security gateway. A path traversal (CWE-22) and improper handling of NULL bytes (CWE-158) let an unauthenticated attacker "write arbitrary files on the underlying system via crafted HTTP or HTTPS requests." Fortinet rates it CVSS 3.1 9.8 and lists the impact as executing unauthorized code or commands. The advisory says the issue "has been reported to be exploited in the wild."

Fortinet's product security team found the bug internally. The workaround points at the Identity-Based Encryption (IBE) web feature. CISA added the CVE to the KEV catalog the same day and gave federal agencies until October 4.

The flaw shipped as a zero-day. When SecurityWeek and Help Net Security reported on October 2, no fixed builds were out, only the workaround. Fortinet updated the advisory with fixed releases on October 5 and clarified the FortiMail Cloud status on October 7.

Who is affected

Affected releases are FortiMail 8.0.0 through 8.0.1, 7.6.0 through 7.6.6, 7.4.0 through 7.4.8, and 7.2.0 through 7.2.9. The fixes are 8.0.2, 7.6.7 and 7.4.9. The 7.2 branch gets no fix, and Fortinet tells those users to upgrade to 7.4 or later. Fortinet updated FortiMail Cloud to 7.6.7 or 8.0.2 on October 5, so cloud customers have nothing to do. The machine-readable product list in the CVE record also includes 7.0.x builds, which the advisory table and description do not mention. If you still run 7.0, treat it as exposed and move to a supported branch.

Do you really need to act?

Yes, if you run FortiMail yourself. A mail gateway is internet-facing by design. Its webmail and IBE pages are commonly reachable from the internet so that outside recipients can retrieve encrypted mail. The bug needs no credentials, is under active exploitation, and gives an attacker a write primitive on an appliance that sees all of your inbound and outbound mail. CISA's enrichment on the CVE record marks it automatable with total technical impact.

Fortinet's indicators suggest what attackers do next. They show an archive account named archive234 configured to ship archives to a remote server at 79.141.169.187. That suggests mail theft, not just a foothold. Fortinet has not said when exploitation began, how many devices were hit, or who is behind it.

FortiMail Cloud customers and organizations without FortiMail can relax.

What to do now

Check the firmware on every appliance and VM with get system status.
Upgrade to 8.0.2, 7.6.7 or 7.4.9 or later. Move 7.2 (and any 7.0) systems to 7.4.9 or later.
If you cannot upgrade today, disable IBE in the GUI (Encryption > IBE > IBE Service off) or from the CLI: config system encryption ibe, set status disable, end. Alternatively, block internet access to the webmail interface and allow only trusted private networks.
If a WAF sits in front of FortiMail, block POST requests to /ibe that contain ../.
Check the indicators below before and after upgrading. A patch blocks new exploitation but does not remove existing persistence or configuration changes.

How to tell if you were hit

Fortinet lists these indicators:

The IPs 79.141.169.187 and 45.129.0.192.
A system event log entry with ui=cron whose command starts /bin/sh -c 'O=/migadmin.
An admin logout with reason=unknown from (null).
A config log entry adding an archive account archive234 with remote-ip[79.141.169.187] and remote-directory[/uploads].
IBE encryption-log errors reading Invalid Base64 Encoding at pos 0. Character=0x2a, alongside Internal user
failed to log in entries.

Also search web and WAF logs for POSTs to /ibe with traversal sequences. If anything matches, assume compromise. Preserve logs and a configuration backup, open a case with Fortinet, rebuild the appliance from clean firmware, and rotate admin passwords, LDAP or directory bind credentials, and other secrets stored on it. Review whether archived mail was sent off-box.

Timeline

Oct 1, 2026 — Fortinet publishes FG-IR-26-175 as an exploited zero-day with a workaround only. CISA adds it to KEV, with a federal deadline of October 4.
Oct 2, 2026 — Press coverage notes that fixed builds 8.0.2, 7.6.7 and 7.4.9 are not yet released.
Oct 5, 2026 — Fortinet updates the advisory with fixed releases and patches FortiMail Cloud.
Oct 7, 2026 — The advisory and CVE record are updated with the FortiMail Cloud clarification (NVD).

Sources

Security digest: October 1, 2026

erroneo.us Security Desk — Thu, 01 Oct 2026 00:00:00 -0700

1 editorial brief, 1 known exploited (cisa kev) addition and 12 critical advisories.

Known exploited (CISA KEV)

CVE-2026-104286 Fortinet FortiMail: Fortinet FortiMail Path Traversal Vulnerability (due 2026-10-04)

Critical advisories

Act now: Cisco SD-WAN Manager CVE-2026-76504: Exploited Auth Bypass

erroneo.us Security Desk — Wed, 30 Sep 2026 00:00:00 -0700

Verdict: Act now. If you run SD-WAN Manager on-prem, upgrade now and check the logs Cisco names; one crafted HTTP request gives an unauthenticated attacker admin over the controller for your whole WAN.

Who must act: Every organization running Cisco Catalyst SD-WAN Manager (vManage) on-prem or in a self-managed cloud, on any configuration, below the first fixed release for its train.
Who can relax: Customers on Cisco-managed SD-WAN Cloud (fixed in 20.15.605, no action needed) and organizations that don't use Catalyst SD-WAN.

Identify every SD-WAN Manager instance and its release.
Upgrade to the first fixed release for your train (20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1 or 26.2.1); migrate off anything older than 20.9.
Block access to the Manager's web and API interfaces from the internet and other untrusted networks, per Cisco's SD-WAN hardening guide.
If the upgrade must wait, apply Cisco's Live Protect shield for CVE-2026-76504 as temporary, partial protection.
Check the logs below; if anything is suspicious, collect request admin-tech output and open a Severity 3 TAC case with CVE-2026-76504 in the title.
After patching, review admin users, API tokens and recent policy or template changes, and rotate admin credentials.

What happened

On September 30, 2026, Cisco published a critical advisory for CVE-2026-76504 (CVSS 3.1 9.8, CWE-177) in Catalyst SD-WAN Manager, formerly vManage. The bug sits in the API's session-based authentication. Because the Manager mishandles URI encoding, a crafted HTTP request can slip past an authentication rule meant to protect a specific API endpoint. The attacker then has API access "with privileges of the admin user," without any credentials. Cisco found the flaw while resolving a TAC support case, and its PSIRT "became aware of active exploitation of this vulnerability in September 2026."

CISA added the CVE to the KEV catalog the same day, with a federal deadline of October 3. Cisco updated the advisory on October 2 to announce a Live Protect shield as a stopgap. BleepingComputer counts it as the fifth Catalyst SD-WAN zero-day exploited in 2026, after CVE-2026-20127, CVE-2026-20182, CVE-2026-20245 and CVE-2026-20262. Rapid7 stresses that this is a separate API authentication path, not the vdaemon peering flaws behind the February and May incidents. Patching for those does not cover this one.

Who is affected

Cisco says the flaw affects SD-WAN Manager "regardless of system configuration." Releases earlier than 20.9 get no fix and must migrate. The first fixed releases are:

Train	First fixed
20.9	20.9.10.1
20.12	20.12.8.2
20.15	20.15.6.1
20.18	20.18.4.1
26.1	26.1.2.1
26.2	26.2.1

Cisco-managed SD-WAN Cloud is fixed in 20.15.605 and needs no customer action. The CVE record carries CISA's "Exploitation: active, Automatable: yes, Technical Impact: total" assessment.

Do you really need to act?

If you operate SD-WAN Manager yourself, yes, now. Admin on the Manager means control of the configuration, templates and policy pushed to every edge router it manages, which BleepingComputer notes can be up to 6,000 devices from one dashboard. Exploitation needs one unauthenticated request, it is confirmed in the wild, and Cisco lists no workaround. The Live Protect shield is described as partial protection only, and it can block legitimate logins that use URI encoding. Exposure matters too: a Manager whose web and API interfaces are reachable from the internet is the obvious target. Isolating it buys time but does not remove the bug. If your WAN is Cisco-managed cloud, or you don't run Catalyst SD-WAN, there is nothing to do.

What to do now

List every on-prem or self-hosted SD-WAN Manager and its release.
Upgrade to the fixed release for your train. Anything earlier than 20.9 needs a migration plan now, because it will not get a fix.
Restrict the Manager's HTTPS and API interfaces to known admin hosts behind a filtering device, as Cisco recommends.
If you can't upgrade this week, deploy the Live Protect shield for CVE-2026-76504, and warn admins about the possible login side effect.
If the logs below show anything unexplained, run request admin-tech and open a Severity 3 TAC case with "CVE-2026-76504" in the title. Cisco asks for this before customers draw their own conclusions about compromise.

How to tell if you were hit

Cisco names two places to look. First, in /var/log/nms/containers/service-proxy/serviceproxy-access.log, look for requests to j_security_check where a character is URI-encoded, for example POST /%6a_security_check. Cisco notes any character can be encoded. A quick pass: grep -i '_security_check' serviceproxy-access.log | grep '%'. Second, in /var/log/nms/vmanage-server.log, look for j_security_check entries from unknown IPs, especially for usernames starting with viptela-reserved-. Some of these entries appear in normal operation, so compare against your baseline. Then review admin accounts and recent template or policy pushes to edge devices.

Timeline

Sep 30, 2026 — Cisco publishes the advisory and fixed releases, saying its PSIRT learned of exploitation earlier in September (exact date not disclosed as of Oct 21, 2026). CISA adds CVE-2026-76504 to KEV.
Oct 2, 2026 — Cisco updates the advisory to announce the Live Protect shield.
Oct 3, 2026 — CISA's remediation deadline for federal agencies.

Sources

Act now: Zammad CVE-2026-102489/102490: Exploited RCE-to-Root Chain

erroneo.us Security Desk — Wed, 30 Sep 2026 00:00:00 -0700

Verdict: Act now. Self-hosted Zammad on 6.x is remotely exploitable and was used in a real breach: upgrade to 7.2.2 today (6.5.5 only as a stopgap), and patch DEB/RPM installs of any version to close the root escalation.

Who must act: Anyone self-hosting Zammad 6.3.0-6.5.4 (remote code execution), and anyone running Zammad from the DEB or RPM packages below 7.2.2 (local root escalation that completes the chain).
Who can relax: Zammad SaaS customers, and self-hosted 7.x installs running from source or the official container images, which neither bug can be used against as published.

Find every self-hosted Zammad and its version and install type (dpkg -l zammad, rpm -q zammad, or the container image tag).
Upgrade to Zammad 7.2.2; if you are stuck on 6.5, install 6.5.5 today and plan the move to 7.2.2.
If you cannot upgrade a 6.x instance now, take it offline or put it behind a VPN, as DIVD advises.
Run DIVD's log check script for CVE-2026-102489 and preserve /var/log/zammad and the web server logs before rebuilding.
If you find signs of compromise, rebuild the host and rotate every credential Zammad stores or can reach, including mail, LDAP and API tokens.

What happened

On September 30, 2026, the Dutch Institute for Vulnerability Disclosure (DIVD) published two CVEs for the open-source Zammad helpdesk and said attackers had used them to breach DIVD itself. According to DIVD's case page, the chain was "abused to breach DIVD" on September 21 and reported to Zammad on September 24.

CVE-2026-102489 is a session hijack (CISA tags it as session fixation) that leads to remote code execution as the zammad service user. It is rated CVSS 4.0 8.7 by DIVD, the CNA, and 9.8 on CVSS 3.1 by NVD.
CVE-2026-102490 is a local privilege escalation from zammad to root. In the DEB and RPM packages, services started as root and ran files that the zammad account could write before dropping privileges. Because those services restart automatically, an attacker could escalate "within seconds." It is rated 8.5 alone and 9.4 when chained.

DIVD told BleepingComputer that after reaching root, the attacker accessed other services and exfiltrated data, and that an AI agent appeared to be choosing the next steps on its own. DIVD called the activity "loud and very, very messy." That is DIVD's assessment from observed behavior, and no actor has been named. CISA added both CVEs to the KEV catalog on October 2 (102489, 102490), with an October 5 deadline.

Who is affected

The disclosure was messy, and the vendor and DIVD initially disagreed. On October 1, Zammad said it could not confirm the privilege escalation because DIVD had not shared details. Zammad later confirmed both. Where things stand now:

RCE (CVE-2026-102489): exploitable on Zammad 6.3.0 through 6.5.4. It sits in the application itself, and the CVE record lists both Linux and Docker installs. The code is present in 7.0.0 through 7.1.x, but both Zammad and DIVD say it is not exploitable there because of the runtime environment. Zammad 7.2.0 added hardening. On October 15, Zammad shipped 6.5.5 as an emergency fix for the unsupported 6.5 series and said it "does not extend its support lifecycle."
Root escalation (CVE-2026-102490): only DEB and RPM packages built with packager.io, from 1.5.0 through 7.2.1, are affected. Source installs and the official container images are not. The fix is 7.2.2, released October 8 with advisory GHSA-p97w-927q-8vxq. Zammad says SaaS customers need no action.

Do you really need to act?

If you self-host Zammad 6.x, yes, today. The RCE needs no credentials, it has been used in a real intrusion, and DIVD is scanning for exposed instances. A helpdesk holds customer conversations, attachments and mail credentials, and it often sits inside the network. On a DEB or RPM install, the second bug turns that foothold into root on the host in seconds.

If you already run 7.x from packages, the remote entry point is closed, but the root escalation still matters. Any other bug or stolen credential that gives code execution as zammad becomes root. Upgrade to 7.2.2 this week. On 7.x via Docker or source, neither published bug applies. Stay current anyway, since Zammad shipped several other security releases in 2026.

What to do now

Identify every instance and how it was installed: dpkg -l zammad or rpm -q zammad for packages, or the image tag in your compose file for Docker.
Upgrade to 7.2.2: apt-get update && apt-get install --only-upgrade zammad or dnf upgrade zammad. For Docker, set the 7.2.2 tag, then docker compose pull && docker compose up -d.
If a 6.5 instance cannot move to 7 today, install 6.5.5 now and schedule the 7.2.2 upgrade. If you cannot do either, take it offline as DIVD advises, or restrict it to a VPN.
Restrict shell access to the Zammad host to trusted administrators, as Zammad's advisory recommends.
If an exposed 6.x instance ran unpatched, rebuild the host and rotate the credentials Zammad stores, including mail accounts, LDAP binds, integrations and API tokens.

How to tell if you were hit

DIVD publishes a log check script for CVE-2026-102489, linked from its case page. Preserve /var/log/zammad and your nginx or Apache logs before you run it, upgrade or rebuild. Sysdig suggests looking for a session reused from a new address shortly after login, and for requests that skip the normal login flow. Also flag shells, download tools or new outbound connections spawned by Zammad's Rails, Puma or worker processes, and any process in that tree running as root. On package installs, look for files in the Zammad install directory changed by the zammad user outside of upgrades. If you find any of these, assume root compromise of the host.

Timeline

Sep 21, 2026 — Attackers use the chain to breach DIVD.
Sep 24, 2026 — DIVD reports the flaws to Zammad. It starts notifying owners of vulnerable instances on Sep 26.
Sep 30, 2026 — The CVE records are published and DIVD discloses the breach.
Oct 2, 2026 — CISA adds both CVEs to KEV.
Oct 8, 2026 — Zammad 7.2.2 fixes the DEB/RPM root escalation.
Oct 15, 2026 — Zammad 6.5.5 ships an emergency fix for CVE-2026-102489 on the 6.5 series.

Sources

Security digest: September 30, 2026

erroneo.us Security Desk — Wed, 30 Sep 2026 00:00:00 -0700

2 editorial briefs, 1 known exploited (cisa kev) addition and 1 critical advisory.

Known exploited (CISA KEV)

CVE-2026-76504 Cisco Catalyst SD-WAN Manager: Cisco Catalyst SD-WAN Manager Hex Encoding Vulnerability (due 2026-10-03)

Critical advisories

Next.js: Remote Code Execution in next/og ImageResponse

Security digest: September 29, 2026

erroneo.us Security Desk — Tue, 29 Sep 2026 00:00:00 -0700

1 known exploited (cisa kev) addition and 2 critical advisories.

Known exploited (CISA KEV)

CVE-2026-86950 Apple Multiple Products: Apple Multiple Products Out-of-Bounds Write Vulnerability (due 2026-10-13)

Critical advisories

Patch this week: Apple CoreGraphics CVE-2026-86950: Exploited Zero-Day

erroneo.us Security Desk — Mon, 28 Sep 2026 00:00:00 -0700

Verdict: Patch this week. A targeted file-parsing zero-day with a fix out since September 28: confirm every iPhone, iPad and Mac is on 26.7.1, 15.8.1 or a 27.x release this week, and today for high-risk users.

Who must act: Anyone managing iPhones, iPads or Macs still on iOS/iPadOS 26 below 26.7.1, macOS Tahoe below 26.7.1 or macOS Sequoia below 15.8.1, most urgently devices used by executives, journalists, administrators and others likely to be singled out.
Who can relax: Devices already on iOS/iPadOS 26.7.1, macOS Tahoe 26.7.1, macOS Sequoia 15.8.1 or the 27.x releases, which the CVE record does not list as affected.

Check every Mac with sw_vers -productVersion and every iPhone and iPad in MDM; anything below 26.7.1 (iOS, iPadOS, Tahoe) or 15.8.1 (Sequoia) needs the update.
Install the update: softwareupdate --install --all --restart on Macs, Settings > General > Software Update on iPhone and iPad.
Enforce a minimum OS version with a deadline in your MDM, and block corporate access from devices that miss it.
Flag Macs on macOS Sonoma and iPhones on iOS 18, which got no update for this bug, for replacement or restricted access.
For high-risk users, turn on Lockdown Mode as general hardening; Apple has not said whether it would have stopped this attack.

What happened

On September 28, 2026, Apple released iOS 26.7.1 and iPadOS 26.7.1, macOS Tahoe 26.7.1 and macOS Sequoia 15.8.1. Each update fixes a single bug, CVE-2026-86950, an out-of-bounds write in CoreGraphics, the system framework that draws 2D graphics, fonts and PDF pages. Apple's description reads: "Processing a maliciously crafted file may lead to arbitrary code execution." Its iOS security note adds: "Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 27." Apple credits Meta Product Security with the report.

CISA added the CVE to the KEV catalog on September 29, with a federal deadline of October 13. CISA's ADP scores it CVSS 3.1 8.8: reachable over the network, no privileges needed, but the victim has to process the file. NVD uses the same score.

Apple has not said who was targeted, how the file was delivered or who was behind the attack. On September 30, researchers at Calif published a root-cause analysis based on a diff of iOS 26.7 and 26.7.1. They found that CoreGraphics was the only library that changed. The bug sits in the glyph rasterizer's float-to-fixed-point coordinate conversion: a glyph's bounding box comes out too small, so the coverage buffer is undersized and aa_cache_render writes past its end. Their trigger is a PDF with a crafted embedded TrueType font. It crashes macOS, and iOS according to Calif, through the ImageIO thumbnail path that apps use to preview attachments. The PoC does not achieve code execution, and Calif did not have the in-the-wild sample. Calif also noticed that a recent WhatsApp build added checks for malformed PDF font programs. It calls that circumstantial evidence of a possible delivery path, and The Hacker News notes that WhatsApp has published no advisory linking the two.

Who is affected

Affected: iPhone 11 and later, plus the iPads listed in Apple's note, on iOS or iPadOS 26 before 26.7.1, and Macs on macOS Tahoe before 26.7.1 (Tahoe note) or Sequoia before 15.8.1 (Sequoia note). Some older iPads, such as the iPad 8th generation, iPad Air 3rd generation and iPad mini 5th generation, cannot move to iOS 27, so they need 26.7.1.

The CVE record lists no other affected versions. Apple shipped iOS 27 and macOS Golden Gate 27 on September 14, and their security notes do not mention this CVE. The 27.0.1 updates released on September 28 have no published CVE entries, according to Apple's security releases page. Apple has not released a fix for macOS Sonoma or for iOS 18 on the iPhone XS and XR. Whether those versions contain the bug is not disclosed as of Oct 21, 2026.

Do you really need to act?

Yes, but this is an inventory job, not a fire drill. Apple describes a targeted attack, not mass exploitation, and the fix has been out for three weeks, so devices that install updates automatically are likely already covered. Two things raise the stakes for everyone else. First, the bug is in file parsing that can run when a received document is merely previewed, so the user interaction required may be small. Second, a public crash trigger and a patch diff now exist, which lowers the cost for others to build a working exploit.

Prioritize people who are plausible targets, and any device that has fallen behind on updates or cannot update at all. Apple has not said whether Lockdown Mode would have blocked the delivery path.

What to do now

Check versions. On Macs, run sw_vers -productVersion. For iPhones and iPads, pull an OS version report from your MDM.
Update anything below the fixed builds. On Macs, run softwareupdate --list, then sudo softwareupdate --install --all --restart. On iPhone and iPad, go to Settings > General > Software Update.
Enforce a minimum OS version with a deadline through MDM, and block corporate access from devices that miss it.
Identify Sonoma Macs and iOS 18 iPhones, which got no update for this bug, and plan to replace them or restrict their access.
For high-risk staff, turn on Lockdown Mode (Settings > Privacy & Security) as general hardening.

How to tell if you were hit

Apple has published no indicators of compromise, and most teams have no reliable way to confirm targeting. A low-cost check is crash reports. Calif's crash ends inside CoreGraphics in aa_cache_render. On Macs, look in ~/Library/Logs/DiagnosticReports and /Library/Logs/DiagnosticReports for .ips files showing CoreGraphics crashes in apps that preview files. On iPhone, look under Settings > Privacy & Security > Analytics & Improvements > Analytics Data. Treat a crash as a lead, not proof: a working exploit may leave no crash at all. If someone may have been singled out, arrange a professional mobile forensics review.

Timeline

Sep 14, 2026 — Apple ships iOS 27 and macOS Golden Gate 27. Their security notes do not list CVE-2026-86950.
Sep 28, 2026 — Apple releases iOS/iPadOS 26.7.1, macOS Tahoe 26.7.1 and macOS Sequoia 15.8.1 with the fix, noting possible exploitation. The CVE is published.
Sep 29, 2026 — CISA adds CVE-2026-86950 to KEV.
Sep 30, 2026 — Calif publishes its root-cause analysis and crash trigger.
Oct 13, 2026 — CISA's remediation deadline for federal agencies.

Sources

Security digest: September 28, 2026

erroneo.us Security Desk — Mon, 28 Sep 2026 00:00:00 -0700

1 editorial brief.

Act now: NetScaler CVE-2026-88771/88772: Exploited Pre-Auth RCE

erroneo.us Security Desk — Sun, 27 Sep 2026 00:00:00 -0700

Verdict: Act now. Every customer-managed NetScaler ADC or Gateway needs the latest build today, and any appliance that was unpatched in September should be investigated as compromised, because patching does not evict attackers.

Who must act: All customer-managed NetScaler ADC and Gateway 14.1 and 13.1 (including FIPS/NDcPP and Secure Private Access hybrid) deployments.
Who can relax: Citrix-managed cloud services and Adaptive Authentication customers, which Citrix updates itself.

Preserve evidence first: VPX snapshot, tech-support bundle, packet engine core dump, remote syslog
Run Citrix's NetScaler Console IOC scan and Unit 42 hunting checks
Upgrade to 14.1-73.41 / 13.1-64.28 (or FIPS equivalents), which also cover the SAML follow-up CVE-2026-88779
If compromised, restore a pre-compromise backup and rotate local passwords, KEKs and SSL certificates
Keep management interfaces off the internet and forward logs to a SIEM
Plan off 13.1, which reached End of Maintenance on September 15, 2026

What happened

On September 27, 2026, Cloud Software Group published bulletin CTX697096 covering eight NetScaler ADC and Gateway flaws and stating that "exploits of CVE-2026-88771 and CVE-2026-88772 on unmitigated NetScaler deployments have been observed." CVE-2026-88771 is an improper input validation bug that lets an unauthenticated attacker run arbitrary commands on any deployment in default configuration. CVE-2026-88772 is a memory overflow reachable when DTLS is enabled, which is the default on VPN virtual servers, and leads to RCE or denial of service. Both are rated CVSS 4.0 9.5 (NVD adds a 3.1 score of 9.8 for CVE-2026-88771). CISA added both to KEV the same day and published an alert.

Unit 42's reconstruction shows these were true zero-days. Fingerprinting began on August 21. From September 4, actors used the DTLS bug to drop .deb web shells. On September 21, they ran a three-stage log-poisoning chain for CVE-2026-88771 against a U.S. target, writing commands into ns.log that a Perl monitoring script then executed. The last observed request came hours before the bulletin. The Hacker News reported that watchTowr had flagged two exploited, unpatched NetScaler RCEs the day before. No actor has been publicly named as of October 21, 2026.

A follow-up came a week later. Patched SAML appliances began rebooting, and on October 3 Citrix published CTX697174 for CVE-2026-88779 (CVSS 4.0 8.7), a memory overflow in SAML SP/IdP configurations. Citrix classifies it as denial of service, but BleepingComputer reported administrators seeing shell commands in crafted usernames. CISA notes that a forced reboot can help code injected via CVE-2026-88771 execute. It entered KEV on October 4. CISA's alert also lists a further identifier, CVE-2026-107406 (October 9), whose bulletin we could not retrieve.

Who is affected

Customer-managed NetScaler ADC and Gateway 14.1 before 14.1-73.37 and 13.1 before 13.1-64.23, plus the FIPS/NDcPP equivalents and Secure Private Access hybrid deployments. SAML users need 14.1-73.41 or 13.1-64.28. Unit 42 counted 50,277 exposed, potentially vulnerable instances on September 27. The 13.1 branch reached End of Maintenance on September 15.

Do you really need to act?

Yes. There is no meaningful precondition: CVE-2026-88771 works in default configuration, exploitation predates disclosure by three weeks, and NetScaler bugs historically turn into mass exploitation within days of disclosure. Patching closes the hole but, as Unit 42 stresses, does not remove persistence an attacker already planted. Anyone who was exposed in September has an investigation to do, not just an upgrade.

What to do now

Before upgrading, preserve evidence: a VPX snapshot, a tech-support bundle, a packet engine core dump, and remote syslog and NetScaler Console logs.
Run the IOC scan Citrix published in NetScaler Console, and CISA's SIGMA rules.
Upgrade straight to 14.1-73.41 or 13.1-64.28 (14.1-73.41 FIPS or 13.1-37.282 FIPS/NDcPP), which covers both bulletins.
For CVE-2026-88778 (TCP ISN prediction), enable Enhanced ISN Generation per Citrix.
If you find compromise, restore a known-good backup from before the compromise, then rotate local passwords, key-encryption keys and SSL certificates, per CISA.

How to tell if you were hit

From Unit 42: search NetScaler logs for pitboss, which on an unpatched device means execution was likely. Check for /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver, /vpn/scripts/linux/nsg64.deb and nsgclient18.deb, a setuid /bin/sh, and unexpected PHP or alias entries in httpd.conf. Treat any requests to /logon/LogonPoint/Authentication/GetUserName as anomalous, and match traffic against the nine IP indicators Unit 42 lists. Post-disclosure attackers may use different tooling, so a clean IOC sweep is not proof of safety.

Timeline

Aug 21, 2026 — Version fingerprinting of NetScaler devices begins.
Sep 4, 2026 — CVE-2026-88772 web shell drops begin.
Sep 15, 2026 — NetScaler 13.1 reaches End of Maintenance.
Sep 21, 2026 — CVE-2026-88771 command injection chain used against a U.S. target.
Sep 27, 2026 — Citrix bulletin CTX697096; both CVEs added to KEV.
Oct 3, 2026 — CTX697174 for SAML flaw CVE-2026-88779; added to KEV Oct 4.
Oct 9, 2026 — CISA alert updated with CVE-2026-107406.

Sources

Security digest: September 27, 2026

erroneo.us Security Desk — Sun, 27 Sep 2026 00:00:00 -0700

1 editorial brief and 2 known exploited (cisa kev) additions.

Known exploited (CISA KEV)

CVE-2026-88772 Citrix NetScaler: Citrix NetScaler Improper Restriction of Operations within the Bounds of a Memory Buffer Vulnerability (due 2026-09-30)
CVE-2026-88771 Citrix NetScaler: Citrix NetScaler Improper Input Validation Vulnerability (due 2026-09-30)

Security digest: September 25, 2026

erroneo.us Security Desk — Fri, 25 Sep 2026 00:00:00 -0700

3 known exploited (cisa kev) additions and 1 critical advisory.

Known exploited (CISA KEV)

CVE-2026-87902 WordPress Core: WordPress Core Remote File Inclusion Vulnerability (due 2026-09-28)
CVE-2026-67279 MikroTik RouterOS: Mikrotik RouterOS Improper Enforcement of Behavioral Workflow Vulnerability (due 2026-09-28)
CVE-2026-65660 Microsoft SharePoint: Microsoft SharePoint Code Injection Vulnerability (due 2026-09-28)

Critical advisories

FriendsOfFlarum OAuth: Unauthenticated account takeover via unverified email trust in Discord OAuth provider

Check exposure: actions-cool Actions Re-Enabled With Mini Shai-Hulud Payload

erroneo.us Security Desk — Thu, 24 Sep 2026 00:00:00 -0700

Verdict: Check exposure. If any workflow referenced either actions-cool action by tag and ran between September 16 and 25, 2026, assume its secrets and repository were compromised; everyone else can confirm with one grep.

Who must act: Owners of repositories whose workflows call actions-cool/issues-helper or actions-cool/maintain-one-comment by a version tag such as @v2.2.1 or @v3, and developers who pulled from those repositories after September 16, 2026.
Who can relax: Repositories that never used these two actions, or pinned them to a full commit SHA verified to predate May 18, 2026; since about September 25, the disabled actions make workflows fail at setup instead of running the payload.

Search .github/workflows/ for actions-cool/issues-helper@ and actions-cool/maintain-one-comment@ and remove or replace them.
Rotate every secret and token reachable by a workflow that ran either action by tag on or after September 16, 2026.
Check default branches for new .claude/settings.json, .claude/setup.mjs, .claude/index.js or .vscode/tasks.json files and revert them.
Before revoking tokens on a developer machine that opened an infected repo, remove gh-token-monitor and kitty-monitor persistence, because the payload ships a wiper.
Pin every third-party action to a full-length commit SHA you have reviewed.

What happened

Two GitHub Actions poisoned during the May 2026 Mini Shai-Hulud campaign came back online in September with their malicious tags still in place. On May 18, 2026, the attacker moved every release tag of actions-cool/issues-helper (53 tags) and actions-cool/maintain-one-comment (15 tags) to new unsigned commits titled Build action for . GitHub disabled both repositories on May 19 but did not rewrite or remove the tags. On September 16, 2026, between 09:09 and 16:16 UTC, both repositories became accessible again. The reason has not been disclosed.

Socket found the reactivation in workflow run histories. Jobs that had been failing in two seconds with "Repository access blocked" suddenly ran for nine to eleven minutes and downloaded actions-cool/issues-helper@v2.2.1. Its September 24 report notes that issues-helper alone has about 15,000 dependent repositories in GitHub's dependency graph. Socket has not determined how many of them reference the action by a mutable tag. The same day, SafeDep documented six newly infected repositories between September 20 and 24, including ant-design/pro-components, jd-opensource/micro-app and MaaXYZ/MaaFramework. It reports the payload is byte-identical to the May build. Socket's September 25 update says both actions were disabled again. The repository page now says access "has been disabled by GitHub Staff due to a violation of GitHub's terms of service."

Who is affected

Any workflow that calls either action by tag (@v2.1.1, @v2.2.0, @v2.2.1, @v3 and so on) and ran while the repositories were live. These are issue-housekeeping bots that run daily or on issue events, so most affected workflows probably fired within a day. The malicious action.yml installs Bun, runs the obfuscated index.js, then calls the real action so the step still passes. On the runner, SafeDep found that it reads the job's ghs_ token from runner memory. It then commits .claude/settings.json (a SessionStart hook), .vscode/tasks.json, .claude/setup.mjs and .claude/index.js into the repository through the GraphQL API, so the commits appear verified as github-actions[bot]. A developer who later pulls and opens that repository in Claude Code or VS Code runs the worm locally. On developer machines it installs the kitty-monitor backdoor and can install the token monitor and its wiper. The May payload itself is covered in our earlier Mini Shai-Hulud brief.

Do you really need to act?

Only if you use these actions, and that takes one search to confirm. If you referenced them by tag and a run succeeded on or after September 16, treat it as a live compromise of that repository's secrets and default branch. Pinning to a commit SHA helps only if that commit is clean: every tag now resolves to attacker commits such as a0c53dd42fc8 (v2.2.1), so pin only a SHA you have verified predates May 18. The second disablement stopped new runs, but hook files already committed stay in place. SafeDep found all six infected default branches still carried them. The general lesson, which GitHub's own guidance repeats, is that tags are mutable and a disabled repository can come back.

What to do now

Find references: grep -rnE 'actions-cool/(issues-helper|maintain-one-comment)@' .github/workflows/, or use GitHub code search across your org. Remove the actions or replace them.
Rotate every secret the affected workflows could read, plus deploy keys and package-registry tokens. Review the job's GITHUB_TOKEN permissions and set permissions: to the minimum.
Revert injected files: git log --since=2026-09-16 --stat -- .claude .vscode/tasks.json, then remove the hooks and force fresh clones for contributors.
On developer machines that opened an infected checkout, remove gh-token-monitor and kitty-monitor persistence before revoking GitHub tokens, then rotate local credentials.
Pin all third-party actions to full-length commit SHAs and review updates before bumping them.

How to tell if you were hit

In the Actions run history, look for the pattern Socket describes: quick setup failures through September 15, then a long successful run on September 16. Job logs that show oven-sh/setup-bun or bun run $GITHUB_ACTION_PATH/index.js inside the action step confirm execution. On the repository side, look for unexpected github-actions[bot] commits adding .claude/ or .vscode/tasks.json. A commit message copied from its parent is another sign: in pro-components, both read 3.1.14-7. SafeDep lists the payload blob 2931c1be43b0, the exfiltration host t.m-kosche.com and commit markers firedalazer and thebeautifulmarchoftime.

Timeline

May 18, 2026 — All tags of both actions are moved to malicious commits (19:10 to 19:31 UTC).
May 19, 2026 — GitHub disables both repositories, leaving the tags unchanged.
Sep 16, 2026 — Both repositories become accessible again, and tag-referencing workflows resume running the payload.
Sep 20–24, 2026 — SafeDep records six newly infected repositories.
Sep 24, 2026 — Socket and SafeDep publish their findings.
Sep 25, 2026 — Both actions are disabled again. BleepingComputer and The Hacker News report the reactivation.

Sources

Security digest: September 24, 2026

erroneo.us Security Desk — Thu, 24 Sep 2026 00:00:00 -0700

1 editorial brief, 2 known exploited (cisa kev) additions and 5 critical advisories.

Known exploited (CISA KEV)

CVE-2026-71362 Adobe Commerce and Magento : Adobe Commerce and Magento Incorrect Authorization Vulnerability (due 2026-09-27)
CVE-2026-5430 WSO2 Multiple Products: WSO2 Multiple Products Path Traversal Vulnerability (due 2026-09-27)

Critical advisories

Security digest: September 23, 2026

erroneo.us Security Desk — Wed, 23 Sep 2026 00:00:00 -0700

3 critical advisories.

Critical advisories

Act now: WordPress Core: Page-Template File Inclusion to RCE

erroneo.us Security Desk — Tue, 22 Sep 2026 00:00:00 -0700

Verdict: Act now. Every WordPress branch back to 4.7 was affected, no login is needed, public scanning tooling exists and attackers are already writing files through pearcmd.php, so confirm you are on a fixed release today.

Who must act: Anyone running self-managed WordPress 4.7 through 7.1.1, especially with a theme that has a top-level page-* directory or PHP with register_argc_argv enabled (official php Docker images, cPanel on PHP below 8.5).
Who can relax: Sites already on 7.1.2 or the patched release for their branch (auto-updates usually handled this), and managed hosts that have confirmed the update in writing.

Confirm each site reports 7.1.2 or the patched release for its branch (wp core version).
Update now from Dashboard > Updates or with wp core update --minor; do not wait for the next maintenance window.
If you cannot update immediately, block requests whose pagename parameter contains encoded traversal (%2e%2e, %252e%252e).
Set register_argc_argv = Off in php.ini where you do not need it, which breaks the pearcmd.php route to code execution.
Check whether your active theme or parent theme has a top-level page-* directory (for example page-templates).
Hunt for unexpected .php files in /tmp and /var/tmp on any host that was unpatched after September 22.

What happened

On September 22, 2026, WordPress shipped version 7.1.2, a security-only release with a single fix, and backported it to every branch back to 4.7. The advisory (CVE-2026-87902, rated critical, CVSS 4.0 score 9.2) says an unauthenticated attacker can make get_page_template() include a chosen readable local .php file from outside the active theme directories. Under certain server and theme conditions, that leads to remote code execution. Robert Ressl reported it.

Patchstack's analysis shows the root cause. WordPress builds a template candidate named page-{pagename}.php from the request's pagename variable, adds a URL-decoded copy, and never passes it through the validate_file() traversal check that the neighboring branch already used. The fix adds that check, plus a new containment test that every resolved template path must pass. CISA added the CVE to the KEV catalog on September 25 with a September 28 due date for federal agencies.

Who is affected

Every WordPress release from 4.7.0 through 7.1.1, which is close to a decade of versions. Fixed releases include 7.1.2, 7.0.6, 6.9.9 and 6.8.10, plus backports on each older branch down to 4.7.37. NVD lists a CISA-ADP CVSS 3.1 score of 8.1 because the attack has preconditions. The advisory names two of them:

Theme: the active child or parent theme has a top-level directory whose name starts with page-, such as page-templates. This applies to the legacy Twenty Twelve and Twenty Fourteen themes and to popular third-party themes including Neve, Hestia and Sydney.
Server: a useful .php target is readable. The well-known one is PEAR's pearcmd.php, which works when register_argc_argv is On. That is the case in the official php Docker image and in default cPanel setups on PHP before 8.5.

Do you really need to act?

Yes, if you run WordPress yourself and are not yet on a fixed release. File inclusion works on any vulnerable site that meets the theme condition. Code execution also needs the server condition, but as Patchstack notes, those settings are common defaults rather than unusual ones.

Exploitation began fast. Patchstack logged first attempts at 11:49 UTC on September 22, built from the patch diff, and the first attempt to write a file through pearcmd at 15:34 UTC. By September 23 traffic had grown more than tenfold and moved through three stages: checking whether the inclusion worked, checking whether pearcmd was reachable, and writing attacker-controlled PHP to /tmp with +config-create. A named Nuclei template was in circulation. Some payloads only drop marker strings, but others run shell commands.

Sites with automatic background updates usually received the fix already. Managed WordPress hosts generally patch core for you, but get confirmation rather than assuming.

What to do now

Check the version on every site: wp core version, or Dashboard > Updates.
Update: wp core update --minor to take the patched release on your branch, or wp core update for 7.1.2. Older sites can take the backport without a major version jump.
If you cannot update today, block requests where pagename contains %2e%2e or %252e%252e, in the query string or the POST body. Real page slugs never contain traversal.
Set register_argc_argv = Off in php.ini where you do not need it, and restart PHP. This does not fix the inclusion, but it breaks the pearcmd chain.
Check your theme: ls wp-content/themes// | grep '^page-'.

How to tell if you were hit

Patchstack's indicators: a pagename parameter containing %2e%2e or %252e%252e, or starting with templates%2f. Also watch for pagename paired with page_id on / or /index.php, any request containing pearcmd, +config-show or +config-create, and the user agents cve-2026-87902-poc/1.0 and nuclei-cve-2026-87902/1.0. An HTTP 200 that returns OPML or RSS output for a normal page URL means a probe succeeded. Run find /tmp /var/tmp -name '*.php' on the host. Patchstack observed filenames such as poc87902.php, wp-pear-rce-flag.php, luci_*.php and zeta_*.php. If you find any, treat the host as compromised: rebuild it, and rotate database credentials and secrets stored in wp-config.php.

Timeline

Sep 17, 2026 — WordPress 7.1.1 ships with 11 unrelated security fixes.
Sep 22, 2026 — WordPress 7.1.2 and backports to 4.7 are released, and GHSA-7hp8-65ch-5whp and CVE-2026-87902 are published. Patchstack sees probing the same day and the first pearcmd file-write attempt at 15:34 UTC.
Sep 23, 2026 — Patchstack reports file writes to /tmp, a tenfold rise in volume, and a public Nuclei template.
Sep 25, 2026 — CISA adds CVE-2026-87902 to KEV, due September 28.

Sources

Patch this week: Linux AF_UNIX CVE-2026-80521: Public Container Escape

erroneo.us Security Desk — Tue, 22 Sep 2026 00:00:00 -0700

Verdict: Patch this week. If you run untrusted or third-party code in containers on a 6.10+ kernel, install fixed kernels as they ship and move that code behind stronger isolation now; a public exploit turns an unprivileged container process into a host compromise.

Who must act: Operators of CI runners, multi-tenant Kubernetes clusters, code-execution sandboxes and shared container hosts on Linux 6.10 or later, or on 6.1/6.6 kernels that carry the new AF_UNIX garbage collector.
Who can relax: Hosts that only run code you already trust can patch on a normal cycle; kernels without the new garbage collector (for example Debian 11, RHEL 6-9 and Ubuntu 22.04's default 5.15 kernel) need nothing.

List container hosts and node kernels (uname -r on each node, or kubectl get nodes -o wide) and flag any that run untrusted code.
Install your distribution's fixed kernel as soon as it ships and reboot or livepatch; on Debian 13 and 12 the fixes are already available.
Until Ubuntu 24.04/26.04 fixes land, move untrusted workloads (CI jobs, code runners, tenant pods) to gVisor, Kata Containers or Firecracker, or to a node pool on an unaffected kernel.
Do not rely on default seccomp, rootless mode, user namespaces or dropped capabilities as mitigations; the vulnerable code is reachable without privileges.
Subscribe to your distribution's tracker entry for CVE-2026-80521 and re-check after each kernel update.

What happened

CVE-2026-80521 is a use-after-free in the Linux kernel's AF_UNIX socket garbage collector. That code cleans up sockets left in reference cycles when file descriptors are passed over UNIX sockets with SCM_RIGHTS. According to the CVE record, a send() that races a concurrent close() can make the collector free a dead group of sockets only partly. A later collector run then walks a freed structure. The one-line upstream fix, "af_unix: Unlink scc_entry in unix_del_edge()", credits Kyle Zeng of OpenAI as the reporter. The kernel CNA published the CVE on August 26, 2026 and scores it CVSS 3.1 7.8.

The bug drew wide attention on September 22. That day depthfirst published research by Zhenpeng (Leo) Lin showing a working container escape on Ubuntu 26.04, with exploit code in a public GitHub repository. depthfirst says it found the bug with its in-house AI model, used it in Google's kernelCTF on July 24, and reported it to the kernel security team on August 5. The team replied that the same bug had already been reported. The upstream patch followed on August 6.

Who is affected

The vulnerable code arrived with a rewrite of the AF_UNIX garbage collector in Linux 6.10 and was backported into 6.1.141+ and 6.6.93+. The CVE record lists fixes in 6.1.189, 6.6.158, 6.12.111, 6.18.53, 7.1.10 and 7.2. Distro kernels backport heavily, so the vendor tracker is what counts, not the version string:

Ubuntu: the Ubuntu tracker (updated October 19) rates it Medium. It lists 26.04 LTS kernels and most 24.04 LTS kernels, including the 6.8 GA kernel, as fixes in progress or still vulnerable, and 22.04's 6.8 HWE kernels as in progress.
Debian: the Debian tracker shows Debian 13 fixed via DSA-6528-1 and Debian 12 fixed in 6.1.190-1 (DLA-4841-1). Debian 11 is not affected.
Red Hat: Red Hat's security data rates it Important, lists RHEL 6 through 9 as not affected, and shows RHEL 10 fixed in kernel 6.12.0-211.65.1.el10_2 (RHSA-2026:81406), with RHEL 10.0 EUS fixed via RHSA-2026:77634. The Red Hat CVE page lists no mitigation.

Do you really need to act?

It depends on whose code runs in your containers. This is a local bug. An attacker first needs to run code on the machine, but any unprivileged process can reach it, including one inside a container. The DevOps Daily analysis notes that default seccomp profiles allow the needed system calls. Rootless containers, user namespaces and dropped capabilities do not help either. That makes the bug serious for CI runners that build untrusted pull requests, multi-tenant clusters, hosted notebooks and "run my code" features, where running code is the whole point.

If every container on a host runs code you wrote and trust, this is a privilege-escalation step an attacker could use after some other compromise. Patch it on a normal but prompt schedule. No exploitation in the wild had been reported as of October 21, 2026, and the CVE is not in CISA KEV. With public exploit code available, expect that to change.

What to do now

Inventory kernels on container hosts: run uname -r on each host, or kubectl get nodes -o wide to see node kernels.
Install fixed kernels where they exist (apt-get update && apt-get install --only-upgrade 'linux-image*' on Debian) and reboot or livepatch. A kernel fix does nothing until the new kernel is running.
On Ubuntu 24.04 and 26.04, watch the tracker. Meanwhile, move untrusted workloads to gVisor, Kata Containers or Firecracker microVMs, or to a node pool on an unaffected kernel.
Do not block AF_UNIX wholesale with seccomp. DevOps Daily notes this breaks many applications.

How to tell if you were hit

To see whether a kernel carries the affected collector, run grep -cE ' unix_(add|del)_edges$' /proc/kallsyms. A result of 0 means the vulnerable code is not present, and the check often works inside a container too. Search dmesg and node logs for oopses or KASAN reports naming unix_gc, unix_walk_scc_fast or a slab use-after-free. Failed exploit attempts can crash hosts. On hosts that ran untrusted containers while unpatched, look for unexpected host-level processes, new SUID binaries and modified runtime binaries. Rotate any secrets the host could read.

Timeline

Jul 24, 2026 — depthfirst exploits the bug against Google's kernelCTF target.
Aug 5, 2026 — depthfirst reports to security@kernel.org and learns the bug was already reported.
Aug 6, 2026 — Upstream fix released, according to depthfirst.
Aug 26, 2026 — The kernel CNA publishes CVE-2026-80521.
Sep 22, 2026 — depthfirst publishes its container-escape research and exploit code.
Oct 3, 2026 — The CVE record is updated with 6.1.189 and 6.6.158 fixes.
Oct 19, 2026 — Ubuntu's tracker still shows 24.04 and 26.04 kernel fixes in progress.

Sources

Check exposure: Graphalgo Malware in Go Modules and Terraform Providers

erroneo.us Security Desk — Tue, 22 Sep 2026 00:00:00 -0700

Verdict: Check exposure. Grep your go.mod, go.sum and Terraform files for four names; if none match you are done, and if one does, treat the machine as compromised.

Who must act: Go developers and infrastructure teams who added gocommunity.io/orderedbtree, gogets.dev/btreex, or the kreuzwenker/docker or gocommunity-io/dockerd Terraform providers, including through a coding task or sample repository someone sent them.
Who can relax: Teams whose dependency files contain none of the four names, and Terraform users whose lock files reference the genuine kreuzwerker/docker provider.

Search Go projects: grep -rnE 'gogets\.dev/btreex|gocommunity\.io/orderedbtree' --include=go.mod --include=go.sum .
Search Terraform code and lock files: grep -rnE 'kreuzwenker/docker|gocommunity-io/dockerd' --include='*.tf' --include='.terraform.lock.hcl' .
Fix the provider source to kreuzwerker/docker and run terraform init -upgrade.
If a match ran anywhere, isolate and reimage the host, then rotate every credential it could reach, cloud and infrastructure credentials first.
Review commits, package publishes, terraform apply runs and CI jobs from that host for unauthorized activity.

What happened

On September 22, 2026, Aikido Security reported four malicious packages carrying a Go port of the Graphalgo malware. There were two Go modules, gocommunity.io/orderedbtree and gogets.dev/btreex, and two Terraform providers, gocommunity-io/dockerd and kreuzwenker/docker. The last is a one-letter typosquat of kreuzwerker/docker, the widely used Docker provider that Aikido says has 56 million reported downloads. The samples share blockchain and Slack infrastructure and a public key with earlier npm samples. ReversingLabs first documented Graphalgo in February 2026. It described the campaign as fake recruiters handing developers coding tasks that pull in malicious npm and PyPI dependencies, and attributed it to Lazarus Group based on technique similarity.

The payloads hide behind triggers. In the Terraform providers, code in resource_docker_container_funcs.go activates only when the SHA-256 of the container name and network ID matches a fixed value, which then serves as an AES key. It decrypts an archive disguised as import-resource.sqlite3 and runs it with a detached go run .. The Go modules fire on a specific "price" integer, and btreex hides its archive in a file named btreex.sql. The second stage is a Go remote access trojan. It checks in with host and user details, takes commands over Slack and over an Ethereum contract on Arbitrum Sepolia, and can run Go or JavaScript code or delete itself.

Who is affected

Only projects that pulled one of the four names. gocommunity.io/orderedbtree was first published on August 11 and gogets.dev/btreex on September 8. The second came with forged commits backdated to November 2025 so the repository looked established. Download counts for the malicious packages were not disclosed as of October 21, 2026. OSV lists both modules as malicious in MAL-2026-17454 and MAL-2026-17453. On October 21, proxy.golang.org refused to serve either module, flagging both as malicious, and the Terraform Registry returned "provider not found" for both providers.

Do you really need to act?

Most teams need one grep and nothing else. Because of the triggers, a casual install may never fire. The payload waits for a repository or Terraform config that supplies the unlocking values. That fits Graphalgo's fake-interview playbook, though Aikido did not say how these packages reached victims. If a candidate exercise, take-home task or "sample infrastructure" repository reached you in August or September, check it. A hit on a machine with cloud or Terraform credentials is serious, because the attacker gets a live remote shell next to your infrastructure keys.

The Go proxy block protects you only if you fetch through proxy.golang.org. With GOPROXY=direct, or a private mirror that cached the modules earlier, they may still resolve.

What to do now

Go: grep -rnE 'gogets\.dev/btreex|gocommunity\.io/orderedbtree' --include=go.mod --include=go.sum . across your repositories, and purge the names from any internal module mirror.
Terraform: grep -rnE 'kreuzwenker/docker|gocommunity-io/dockerd' --include='*.tf' --include='.terraform.lock.hcl' .. Correct the required_providers source to kreuzwerker/docker and run terraform init -upgrade.
On any match that ran, isolate and reimage the host. The command-and-control channels may still reach it.
Rotate every credential the host could read, starting with cloud and Terraform credentials. Then review its commits, publishes, terraform apply runs and CI jobs.
Where build hosts have no business talking to blockchain RPC services or Slack, alert on that traffic.

How to tell if you were hit

Search provider caches (.terraform/providers, ~/.terraform.d/plugins) for import-resource.sqlite3 with SHA-256 5f892a54…977d0f. Search the Go module cache ($(go env GOMODCACHE)) for btreex.sql with SHA-256 ab01686d…5d62f5. Look for detached go run . processes spawned by terraform or test runs. Check DNS and proxy logs for gocommunity.io, gogets.dev, the Slack workspaces portfolio-devs and portfolio-testers, and calls to Arbitrum Sepolia contract 0xAD02b5cDE693529d3bdA0266299501ad0193036C.

Timeline

Feb 11, 2026 — ReversingLabs documents the Graphalgo fake-recruiter campaign on npm and PyPI.
Aug 11, 2026 — gocommunity.io/orderedbtree is first published.
Sep 8, 2026 — gogets.dev/btreex is first published. The gocommunity-io/dockerd provider appears in early September.
Sep 22, 2026 — Aikido publishes its research, updated Sep 24.
Oct 2, 2026 — OSV publishes MAL-2026-17453 and MAL-2026-17454.

Sources

Security digest: September 22, 2026

erroneo.us Security Desk — Tue, 22 Sep 2026 00:00:00 -0700

3 editorial briefs, 4 known exploited (cisa kev) additions and 4 critical advisories.

Known exploited (CISA KEV)

CVE-2026-94127 F5 BIG-IP APM: F5 BIG-IP APM Heap-based Buffer Overflow Vulnerability (due 2026-09-25)
CVE-2026-93952 Arista VeloCloud Orchestrator: Arista VeloCloud Orchestrator Improper Input Validation Vulnerability (due 2026-09-25)
CVE-2026-93616 Check Point Multiple Products: Check Point Multiple Products Path Traversal Vulnerability (due 2026-09-25)
CVE-2026-85102 Check Point Multiple Products: Check Point Multiple Products Improper Certificate Validation Vulnerability (due 2026-09-25)

Critical advisories

Security digest: September 21, 2026

erroneo.us Security Desk — Mon, 21 Sep 2026 00:00:00 -0700

1 known exploited (cisa kev) addition.

Known exploited (CISA KEV)

CVE-2026-7273 Zyxel GS1900 Series Switches: Zyxel GS1900 Series Switches Stack-Based Buffer Overflow Vulnerability (due 2026-09-24)

Patch this week: Linux Kernel: Five Exploited Root Bugs Added to CISA KEV

erroneo.us Security Desk — Fri, 18 Sep 2026 00:00:00 -0700

Verdict: Patch this week. Five local root bugs, all with fixes and most with public exploits, are now confirmed exploited; get every Linux host onto a current kernel and reboot this week, container hosts, CI runners and shared servers first.

Who must act: Anyone running Linux kernels older than their distribution's July to September 2026 security updates, most urgently where containers, CI jobs or untrusted users share a kernel.
Who can relax: Hosts already booted into current distribution kernels (for example RHEL kernels from Sep 22-24, 2026, Debian 12 6.1.177-1+, Ubuntu 24.04 6.8.0-147.147+); single-user machines face local-only risk.

Run uname -r on every Linux host and compare it with your distribution's fixed kernel for each CVE.
Install the current kernel and reboot, starting with container hosts, Kubernetes nodes, CI runners and multi-user servers.
If a reboot must wait, block the tls module where kTLS is unused and remove ebtables SNAT rules that rewrite ARP addresses (Red Hat's interim mitigations).
For untrusted containers, deny AF_ALG sockets with seccomp, and where rootless containers are not needed, set user.max_user_namespaces=0 (Red Hat's workaround for CVE-2026-53362).
Ask appliance and embedded-Linux vendors for fixed firmware; the CVE records link Siemens advisories for three of these bugs.

What happened

Between August 26 and September 18, 2026, CISA added five Linux kernel bugs to its Known Exploited Vulnerabilities catalog. All five let a local user corrupt kernel memory and, in practice, become root. All had upstream fixes before they were listed. CISA has not said who is exploiting them or against whom, and every entry carries its forensic-triage requirement. The Hacker News reports that Red Hat updated its advisories for the September batch on September 19 to acknowledge exploitation and "known public exploits."

CVE-2025-39682 (kTLS): a zero-length record on the kernel TLS receive list leads to a use-after-free. The CVE record and NVD score it 9.8 as network-reachable. Red Hat scores it 7.0 and says it is remotely triggerable "only when kernel TLS ... is in use." A kernelCTF exploit published in February 2026 sets up its own loopback kTLS connection.
CVE-2025-39964 (AF_ALG): two threads writing to one crypto socket corrupt its state. The code dates to Linux 2.6.38. Its kernelCTF write-up, added August 11, 2026, needs no capabilities and no user namespaces. Cyber Security News credits STAR Labs and reports a Docker escape in a proof-of-concept setup.
CVE-2026-53266 (ebtables SNAT): an ARP address rewrite copies a MAC address straight into a splice-imported file page. The CNA scores it 8.8 and notes that the required CAP_NET_ADMIN can come from a user namespace.
CVE-2026-53362 ("Fraggap"): a 15-byte out-of-bounds write in the UDPv6 send path. It was disclosed on July 20 with a public exploit used in kernelCTF. Red Hat's RHSB-2026-009 warns of container escape and SELinux bypass.
CVE-2022-0995 (watch_queue): an out-of-bounds write in the notification filter, fixed in March 2022. The CVE record links two public exploits on Packet Storm. CISA added it in a batch of six mostly older bugs.

None of these is Copy Fail (CVE-2026-31431), but two are close relatives. The AF_ALG race sits in the same socket family, and the CVE record says skcipher sockets reach it too, so blocking only algif_aead does not help. The ebtables bug, like Copy Fail, ends with the kernel writing into a file's cached page.

Who is affected

Taking the highest fix per stable line from the CVE records, 5.10.259, 5.15.210, 6.1.177, 6.6.144, 6.12.95, 6.18.38 and 7.1.3 cover every bug here that applies to that line. Distribution status differs:

RHEL: Red Hat's CVE data lists Fraggap as RHEL 10 only and the kTLS bug as not affecting RHEL 8. No shipped RHEL kernel was affected by CVE-2022-0995. The AF_ALG and ebtables bugs reach RHEL 7 ELS through 10. Kernels from September 22-24, 2026 cover all five.
Debian: the security tracker lists bookworm fixed in 6.1.177-1 and trixie in 6.12.95-1. Bullseye is fixed in 5.10.259-1 and not affected by the kTLS or IPv6 bugs.
Ubuntu: 24.04 needs 6.8.0-147.147 for Fraggap, and several 24.04 HWE and OEM kernels were still listed as vulnerable. For the ebtables bug, 22.04 is fixed in 5.15.0-198.208 and 20.04 is still listed as vulnerable.

Do you really need to act?

Yes, but on a "this week" clock, not "drop everything." Every bug needs code already running on the box. That makes them second-stage tools, used after a phished account, a compromised web app or a malicious CI job. Where tenants share a kernel, the AF_ALG bug needs no special configuration. Fraggap needs IPv6, and Red Hat adds the ability to create network namespaces, which RHEL 10 grants by default. Both have public root exploits. The ebtables bug also needs namespace privileges. Red Hat calls its exposure limited to systems with specific bridge rules. On single-user servers and laptops, risk is lower. If you have installed and booted a kernel from late September 2026 or later, you are done.

What to do now

Inventory kernels: uname -r everywhere, then rpm -q kernel or apt list --installed 'linux-image*'.
Update and reboot: dnf update kernel or apt-get install --only-upgrade linux-image-generic, then reboot into the new kernel.
If the reboot must wait, follow Red Hat's interim mitigations: blacklist tls where kTLS is unused, and remove ebtables SNAT rules that rewrite ARP addresses.
Where rootless containers are not needed, apply RHSB-2026-009's workaround, sysctl -w user.max_user_namespaces=0. Deny socket(AF_ALG, ...) in seccomp profiles for untrusted workloads.
Ask appliance vendors for fixed firmware. The CVE records link Siemens advisories for three of these bugs.

How to tell if you were hit

The Cloud Security Alliance notes that CISA has disclosed no details of the intrusions, and we found no published indicators as of Oct 21, 2026. Look for unexpected writes to /proc/sys/kernel/core_pattern, which the public Fraggap, AF_ALG and kTLS exploits all abuse. Also look for root processes descended from unprivileged users or containers, and kernel oopses that mention tls, af_alg, ebt_snat or ip6_append_data in journalctl -k. Capture memory and logs before rebooting a suspect host.

Timeline

Mar 11, 2022 — watch_queue fix for CVE-2022-0995 committed upstream.
Sep 5, 2025 — CVE-2025-39682 (kTLS) published with stable fixes.
Oct 13, 2025 — CVE-2025-39964 (AF_ALG) published.
Jun 25, 2026 — CVE-2026-53266 (ebtables) published.
Jul 20, 2026 — Fraggap (CVE-2026-53362) write-up and exploit published.
Aug 26, 2026 — CISA adds CVE-2022-0995 to KEV. CVE-2026-53362 follows on Aug 27.
Sep 18, 2026 — CISA adds CVE-2025-39682, CVE-2025-39964 and CVE-2026-53266, with a federal deadline of Sep 21.

Sources

Security digest: September 18, 2026

erroneo.us Security Desk — Fri, 18 Sep 2026 00:00:00 -0700

1 editorial brief, 3 known exploited (cisa kev) additions and 5 critical advisories.

Known exploited (CISA KEV)

CVE-2026-53266 Linux Kernel: Linux Kernel Out-of-Bounds Write Vulnerability (due 2026-09-21)
CVE-2025-39964 Linux Kernel: Linux Kernel Race Condition Vulnerability (due 2026-09-21)
CVE-2025-39682 Linux Kernel: Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability (due 2026-09-21)

Critical advisories

Check exposure: Plugin4Shell: Plugin Pin Bypass in AI Coding Agents

erroneo.us Security Desk — Thu, 17 Sep 2026 00:00:00 -0700

Verdict: Check exposure. Claude Code and Codex users on current versions are fixed; the real exposure is Copilot or Gemini CLI plugins that auto-update from repositories hosted outside GitHub.

Who must act: Teams that install third-party plugins in GitHub Copilot or Gemini CLI, run Claude Code older than 2.1.179 or Codex older than 0.146.0, or run an internal plugin marketplace on Bitbucket or a self-hosted git server.
Who can relax: Claude Code and Codex users on auto-update with no Copilot or Gemini CLI plugins, and anyone who installs no third-party agent plugins at all.

Confirm versions: claude --version should report 2.1.179 or later and codex --version 0.146.0 or later; update with claude update or npm i -g @openai/codex@latest.
Inventory installed agent plugins and the git host behind each plugin and marketplace; flag anything on Bitbucket or a self-hosted server.
For Copilot, disable automatic plugin updates where you can and remove plugins sourced from hosts that allow SHA-shaped branch names.
Plan a migration off Gemini CLI; Google directs users to Antigravity instead of patching.
If you run an internal marketplace, host plugins only where 40-hex branch names are rejected, and make install tooling check that git rev-parse HEAD equals the pinned SHA.

What happened

On September 17, 2026, Air Security published Plugin4Shell. The flaw breaks the SHA pinning that plugin marketplaces for AI coding agents use to lock a plugin to a reviewed commit. Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI all cloned the plugin repository and checked out the pinned commit. None of them confirmed that the checkout actually landed on that commit.

Two git behaviors make that gap exploitable by whoever controls the plugin repository:

Claude Code, Codex, Copilot: the attacker creates a branch whose name is the 40-character pinned SHA and makes it the default branch. Git prefers a ref over a commit with the same name, so git checkout lands on the attacker's branch.
Gemini CLI: it fetches the pinned commit and then runs git checkout FETCH_HEAD. A default branch named FETCH_HEAD wins, and the fetched commit is discarded.

Air calls it zero-click because background plugin auto-update, the default in Claude Code and Codex, re-runs the checkout whenever the marketplace bumps the pin. The pinned commit can stay benign for review while the name resolves to malicious code. Air built working exploits for all four agents. It reports no exploitation in the wild, and the CVE is not in CISA KEV.

Who is affected

Anthropic's advisory, GHSA-pq7j-f95f-qfcv, covers the plugin install flow in Claude Code and Claude Desktop before 2.1.179. It was published on October 9, with CVE-2026-86063 following on October 13. The CVE record scores it CVSS 4.0 7.5, and the GitHub advisory 7.7. Anthropic says auto-updating installs already have the fix. Codex fixed it in 0.146.0, released July 29, whose changelog lists "Verify Git plugin SHA checkouts" (#34644). At disclosure, Microsoft had shipped no client fix for Copilot. Google has declined to patch Gemini CLI, which is deprecated in favor of Antigravity.

Do you really need to act?

Only if you use third-party agent plugins, and the urgency depends on where they are hosted. The branch-name variant needs a host that accepts 40-hex branch names. Air notes that GitHub rejects them, while Bitbucket and self-hosted git servers allow them. Plugins hosted on GitHub are therefore out of reach of that variant. The Gemini CLI variant does not depend on the host, as the Cloud Security Alliance points out.

The realistic attacker publishes a useful plugin, gets it approved, and later swaps the code, or takes over a trusted plugin's repository. Air's earlier research is a warning about scale: a test plugin of theirs reached more than 26,000 agents before it was pulled.

What to do now

Check claude --version (2.1.179 or later) and codex --version (0.146.0 or later). Update with claude update or npm i -g @openai/codex@latest.
List every installed plugin and marketplace and the git host behind each. Anything on Bitbucket or a self-hosted server needs a closer look.
For Copilot, disable automatic plugin updates where possible and remove plugins you cannot verify. That removes the zero-click element.
Move Gemini CLI users to a maintained tool.
If you run an internal marketplace, add the check Air suggests to your install tooling: test "$(git rev-parse HEAD)" = "" || exit 1.

How to tell if you were hit

In each plugin's local git checkout, look for hash-named or FETCH_HEAD branches with git for-each-ref --format='%(refname)' | grep -E '/([0-9a-f]{40}|FETCH_HEAD)$'. Compare git rev-parse HEAD with the pin in the marketplace manifest. A mismatch means the pin was bypassed, so treat the plugin's code as untrusted and review what it ran. For Claude Code, the plugin loading reference puts marketplace clones under ~/.claude/plugins/marketplaces/ and installed copies under ~/.claude/plugins/cache////. Also look for hooks, MCP server entries or scripts in recently updated plugins that the reviewed commit did not contain.

Timeline

May 2026 — Air Security finds the flaw and builds proofs of concept for all four agents.
Jun 17, 2026 — Anthropic confirms the fix in Claude Code 2.1.179.
Jul 29, 2026 — Codex 0.146.0 ships with plugin SHA checkout verification.
Aug 4, 2026 — Google says Gemini CLI will not be fixed.
Sep 17, 2026 — Air publishes Plugin4Shell. Help Net Security reports it on Sep 18.
Oct 9, 2026 — Anthropic publishes GHSA-pq7j-f95f-qfcv. CVE-2026-86063 is published on Oct 13.

Sources

Security digest: September 17, 2026

erroneo.us Security Desk — Thu, 17 Sep 2026 00:00:00 -0700

1 editorial brief and 9 critical advisories.

Critical advisories

Act now: Cisco ISE CVE-2026-76460: Exploited CVSS 10 Auth Bypass

erroneo.us Security Desk — Wed, 16 Sep 2026 00:00:00 -0700

Verdict: Act now. If you run Cisco ISE or ISE-PIC on any release before the fixed patches, patch now and hunt every node; the bug needs no login, is exploited, and Cisco warns attackers may get root and erase their tracks.

Who must act: Every organization running Cisco Identity Services Engine or ISE Passive Identity Connector 3.0 through 3.5 for network access control, RADIUS/TACACS+ or identity services, in any deployment size.
Who can relax: Organizations that do not run Cisco ISE or ISE-PIC; other Cisco products are not named in this advisory.

Inventory every ISE and ISE-PIC node in every deployment and record its release and patch level.
Install 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 or 3.5 Patch 4 on all nodes; migrate ISE 3.0 to a supported release.
Until patched, use infrastructure ACLs so only required management and control-plane traffic can reach ISE nodes.
On every node, check the API gateway access log for suspicious usernames, starting with show logging application ise-kong/access.log | include dummyuser.
If you find signs of compromise, re-image the affected nodes, restore configuration from a known-good backup, and rotate ISE admin, RADIUS/TACACS+ shared secrets and integration credentials.

What happened

On September 16, 2026, Cisco published CVE-2026-76460, an authentication bypass in an API of Cisco Identity Services Engine (ISE) and ISE Passive Identity Connector (ISE-PIC). The cause is "insufficient authentication control on an API endpoint". An unauthenticated attacker who sends a crafted request to that endpoint gets into the device without going through the web-based management interface. Cisco scores it CVSS 3.1 10.0 (Critical) and says its PSIRT is aware of active exploitation. Cisco also warns that after a successful exploit, "threat actors may obtain command execution with root privileges" and may then remove or hide evidence.

CISA added the CVE to the Known Exploited Vulnerabilities catalog the same day, with a September 19 deadline for federal agencies. Its ransomware status is "Unknown", and CISA flags it for forensic triage. CISA's assessment in the CVE record rates exploitation automatable and the technical impact "total". Cisco found the bug while resolving a TAC support case and has not described the attacks.

Who is affected

ISE and ISE-PIC are affected regardless of configuration. The first fixed releases are:

3.1: 3.1 Patch 12
3.2: 3.2 Patch 11
3.3: 3.3 Patch 12
3.4: 3.4 Patch 7
3.5: 3.5 Patch 4

ISE 3.0 has reached end of software maintenance, and Cisco tells those customers to migrate to a supported fixed release. Help Net Security notes that the same release fixed many other ISE flaws, and that 3.1 and 3.2 now receive only critical fixes. That makes 3.3 Patch 12, 3.4 Patch 7 or 3.5 Patch 4 the better targets. There is no workaround.

Do you really need to act?

If you run ISE, yes, today. Every precondition favors the attacker: no credentials, no user interaction, no special configuration, and a changed scope in the CVSS vector. ISE sits at the center of network access control, and a compromised ISE node can change who gets onto wired, wireless and VPN networks. It also holds RADIUS and TACACS+ shared secrets, network device credentials and directory integrations. Cisco's warning about root access and evidence removal means that patching alone does not prove you are clean.

ISE is usually deployed on internal networks, which narrows the field of attackers. It does not remove the risk, because Cisco documents no specific port or interface for the vulnerable API, and an attacker with any internal foothold can reach it. Cisco's only interim mitigation is infrastructure ACLs that allow just the management and control-plane traffic each node needs. Bitsight also stresses that this does not replace patching. If you do not run ISE, nothing here applies to you, though it is worth asking managed network providers whether they do.

What to do now

List every ISE and ISE-PIC node, including secondary admin, monitoring and policy service nodes in distributed deployments. Check the release and installed patch with show version on each node.
Install the fixed patch for your train on all nodes, or migrate 3.0 deployments to a supported release.
Until every node is patched, apply infrastructure ACLs so only the management stations and network devices that need ISE can reach it.
Run the indicator check on every node, not just the primary: show logging application ise-kong/access.log | include dummyuser.
If anything looks suspicious, follow Cisco's advice: re-image the affected nodes and restore configuration from backup. Then rotate the ISE admin passwords, RADIUS/TACACS+ shared secrets and the service accounts ISE uses for Active Directory and other integrations.

How to tell if you were hit

Cisco's indicator lives in the API gateway (Kong) access log. Look for suspicious usernames, with dummyuser as a non-exhaustive example, and treat any matching entry as possible malicious activity. The live log only covers recent traffic. For older entries, collect a support bundle with debug logs included and shared-key encryption, decrypt it, and search ./ise/logs/apigateway/access.log.*.gz. Because an attacker with root can wipe local logs, Cisco recommends checking telemetry outside the device as well: firewall and network logs showing unexpected uploads from ISE nodes to external IPs, or downloads from malicious addresses. Also review admin accounts, authorization policies and network device entries for changes you cannot explain.

Timeline

Sep 16, 2026 — Cisco publishes the advisory and fixed patches, citing active exploitation. CISA adds CVE-2026-76460 to KEV.
Sep 17, 2026 — CISA's exploitation assessment is added to the CVE record, and press and vendor write-ups follow.
Sep 19, 2026 — CISA's remediation deadline for federal agencies.

Sources

Security digest: September 16, 2026

erroneo.us Security Desk — Wed, 16 Sep 2026 00:00:00 -0700

1 editorial brief, 3 known exploited (cisa kev) additions and 3 critical advisories.

Known exploited (CISA KEV)

CVE-2026-87886 Acronis Backup: Acronis Backup Incorrect Default Permissions Vulnerability (due 2026-09-19)
CVE-2026-76460 Cisco Identity Services Engine: Cisco Identity Services Engine Incorrect Use of Privileged APIs Vulnerability (due 2026-09-19)
CVE-2026-58704 Google Pixel: Google Pixel Improper Authorization Vulnerability (due 2026-09-19)

Critical advisories

Patch this week: Google Pixel Modem CVE-2026-58704: Exploited Zero-Day

erroneo.us Security Desk — Tue, 15 Sep 2026 00:00:00 -0700

Verdict: Patch this week. A targeted, no-interaction modem bug on Pixel phones with a fix already out: make 2026-09-05 the minimum patch level for every managed Pixel this week, and sooner for high-risk users.

Who must act: Organizations with company-owned or BYOD Pixel phones that access corporate data, especially those used by executives, administrators, journalists or staff who travel.
Who can relax: Fleets with no Pixel phones, and Pixel devices already on patch level 2026-09-05 or later, since Google's bulletin covers only Google devices.

Pull the security patch level of every managed Pixel from your MDM and list any device below 2026-09-05.
Set a compliance rule that blocks corporate access for Pixel devices below patch level 2026-09-05.
Push or prompt the update on non-compliant devices, starting with high-risk users.
Retire Pixel models that no longer get security updates (Pixel 5a and older), since they will not receive this fix.
For high-risk users whose phones stayed unpatched, arrange a professional mobile forensic review.

What happened

On September 15, 2026, Google published the Pixel Update Bulletin for September 2026. One fix was for CVE-2026-58704, an elevation-of-privilege bug in the Pixel's Modem component, rated High. The bulletin carries a rare note: "There are indications that CVE-2026-58704 may be under limited, targeted exploitation." Google's CVE text says that in the cellular modem "there is a possible permission bypass due to a logic error in the code." It "could lead to remote (proximal/adjacent) escalation of privilege with no additional execution privileges needed." User interaction is not needed.

CISA added the bug to the KEV catalog on September 16 and gave federal agencies until September 19. The entry is also flagged for CISA's forensic triage requirements. Google has not named the attacker, the victims or how the exploit was delivered. SecurityWeek notes that Google "has not attributed the exploitation to a specific threat actor." No outside reporter is credited.

Who is affected

Google Pixel phones below security patch level 2026-09-05 are affected. The bulletin says "All supported Google devices will receive an update to the 2026-09-05 patch level," but it does not list which models carry the flaw. Per Google's support page, Pixel 6 and later, plus the Pixel Fold, are in their update windows. Pixel 5a and older get no security updates at all. The bug ID has an asterisk, which means the fix is not public source code and ships in Pixel binary drivers. Google's bulletin covers only Google devices. Whether other phones share the flawed code has not been disclosed.

The sources disagree on a few details. Google, the CNA, gave no CVSS score. The 8.8 figure (AV:A, no privileges, no interaction) comes from CISA's enrichment, shown on NVD. The Hacker News cites 8.0. The KEV entry calls it improper authorization but lists CWE-693. The CVE record's affected field says "Android kernel", while the description says cellular modem.

Do you really need to act?

For managed Pixel fleets, yes, this week. Three things push it up: the bug is in the modem, it needs no click, and Google has seen real use. "Proximal/adjacent" means the attacker has to be near the phone or on an adjacent network, not anywhere on the internet. That fits the profile of a targeted operation against chosen people, not mass exploitation. Most employees are unlikely targets. But you cannot easily tell who is one, and the fix is a routine update that has been out for five weeks. Patch everyone, and start with people whose phones are worth an exploit: executives, admins with production access, legal, and staff who travel.

If your organization has no Pixels, there is nothing to do for this CVE. Pixel phones already on 2026-09-05 or later, including the October update, are covered.

What to do now

Export the security patch level for every Pixel from your MDM. On a single device, run adb shell getprop ro.build.version.security_patch and expect 2026-09-05 or later.
Add a compliance rule that blocks email, VPN and SSO access for Pixels below 2026-09-05.
Push or prompt the system update on non-compliant devices. Follow up by hand with high-risk users.
Replace any Pixel 5a or older still in use. It will never get this fix.
For BYOD Pixels, tell owners why the minimum patch level matters, so blocked access is not a surprise.

How to tell if you were hit

Hard to say, and Google has not helped. As of October 21, 2026, it has published no indicators, payload names or attacker details. Modem-level exploitation leaves little that an MDM or an on-device app can see. In practice:

Any Pixel below 2026-09-05 during August and September was exposed. Most were almost certainly not targeted.
If a high-risk user's phone was unpatched and showed unexplained reboots, overheating, battery drain or data use, hand it to a mobile forensics specialist. Do not just update it and move on, because updating can destroy evidence.

Timeline

Jul 2, 2026 — Google's device CNA reserves CVE-2026-58704.
Sep 15, 2026 — Google publishes the September Pixel bulletin (patch level 2026-09-05) with the limited, targeted exploitation note.
Sep 16, 2026 — CISA adds the CVE to KEV.
Sep 19, 2026 — CISA's remediation deadline for federal agencies.
Oct 7, 2026 — The CVE record's CISA enrichment, which carries the 8.8 score, is last updated.

Sources

Check exposure: Acronis Backup cPanel Plugin CVE-2026-87886: Exploited LPE

erroneo.us Security Desk — Tue, 15 Sep 2026 00:00:00 -0700

Verdict: Check exposure. Only hosting servers running the Acronis Backup plugin for cPanel & WHM, Plesk or DirectAdmin are affected; on those, especially multi-tenant cPanel boxes, update the plugin now because it is being exploited.

Who must act: Hosting providers and server admins with the Acronis Backup plugin or extension installed on Linux cPanel & WHM, Plesk or DirectAdmin servers, above all shared-hosting servers where many users or websites have local access.
Who can relax: Everyone without these specific Acronis hosting-panel integrations, including users of other Acronis products not listed in SEC-10986.

Inventory every cPanel & WHM, Plesk and DirectAdmin server with the Acronis Backup plugin or extension installed.
Update cPanel & WHM servers to plugin 1.9.3 HF3 (build 1.9.3.1021) or later first, since that is where exploitation was seen.
Update the Plesk extension to 1.8.11 (build 1.8.11.638) and the DirectAdmin plugin to build 1.2.3.238 or later.
Confirm the installed build on each server after updating rather than trusting automatic updates.
On shared-hosting servers, review which users and sites have shell or script execution, and hunt for signs of local compromise.

What happened

Acronis has disclosed CVE-2026-87886, a local privilege escalation in its Backup integrations for web hosting control panels. Advisory SEC-10986 calls it "local privilege escalation due to insecure file permissions" (CWE-276), rated CVSS 3.0 7.8. It also states: "Exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments."

The fixes shipped quietly before the disclosure. The Plesk extension 1.8.11 update is dated September 10 and the cPanel & WHM plugin 1.9.3 HF3 update September 11. On September 15, Acronis revised both entries to link SEC-10986. The cPanel note now says the update "should be installed immediately by all users" and repeats the exploitation warning. The Plesk note says Acronis sees "no signs of active exploitation." CISA added the CVE to the KEV catalog on September 16, with a federal deadline of September 19. The CVE record was published on September 17.

Who is affected

Three Linux products are affected:

Acronis Backup plugin for cPanel & WHM before build 1.9.3.1021 (fixed in 1.9.3 HF3)
Acronis Backup extension for Plesk before build 1.8.11.638
Acronis Backup plugin for DirectAdmin before build 1.2.3.238

CISA's KEV entry names only the cPanel and Plesk products. The vendor advisory and the CVE record include DirectAdmin as well. No other Acronis products are listed in SEC-10986.

Do you really need to act?

Most developers and companies can skip this one. It matters only if you run hosting servers with one of these panel integrations installed. If you do, the "local" in local privilege escalation offers less comfort than it sounds. The CVSS vector requires low privileges and no user interaction. On a shared cPanel server, low privileges describe every hosting customer, and every website whose CMS or plugin an attacker can turn into a web shell. Escalating from there threatens every tenant on the box, and the backups too. CISA's enrichment on the CVE record rates the technical impact "total" and automatability "no," consistent with a second-stage bug used after an initial foothold.

Very little is known about the attacks. The Hacker News reports there are no details on the attackers, their goals, or how long exploitation went on, and an Acronis spokesperson had "nothing to add at this stage." Help Net Security likewise says it is unknown what attackers do after escalating. As of October 21, 2026, there is no public proof-of-concept and no published root-cause write-up.

What to do now

List every cPanel & WHM, Plesk and DirectAdmin server with the Acronis Backup integration installed. On Plesk, plesk bin extension --list shows installed extensions and versions. On cPanel or DirectAdmin hosts, check the plugin's version in the panel, or with rpm -qa | grep -i acronis where it is packaged as an RPM.
Update cPanel & WHM servers to 1.9.3 HF3 (build 1.9.3.1021) or later first.
Update Plesk to 1.8.11 (build 1.8.11.638) and DirectAdmin to build 1.2.3.238 or later.
Re-check the installed build afterward. Don't assume the update arrived.
On multi-tenant servers, take stock of which accounts have shell access or can run scripts, and tighten that where you can.

How to tell if you were hit

Acronis has not published indicators of compromise as of October 21, 2026, so hunting means looking for local escalation in general. Start where a local attacker would get in: web shells and unfamiliar scripts in customer document roots. Then look for what escalation leaves behind: new setuid binaries (find / -xdev -perm -4000 -mtime -60), unknown root cron jobs, keys you didn't add in /root/.ssh/authorized_keys, and recently modified files in the Acronis plugin's install directories. If you find a confirmed local compromise on a cPanel server that ran a vulnerable build, assume root-level access. Rebuild the host, then rotate panel, database and backup-storage credentials.

Timeline

Sep 10, 2026 — Acronis releases the fixed Plesk extension, 1.8.11.
Sep 11, 2026 — Acronis releases the cPanel & WHM plugin 1.9.3 HF3.
Sep 15, 2026 — Acronis updates both entries, links SEC-10986 and reports exploitation against cPanel & WHM.
Sep 16, 2026 — CISA adds the CVE to KEV (due Sep 19).
Sep 17, 2026 — The CVE record is published.

Sources

Security digest: September 15, 2026

erroneo.us Security Desk — Tue, 15 Sep 2026 00:00:00 -0700

2 editorial briefs and 3 critical advisories.

Critical advisories

Act now: Cisco Secure Email Gateway: Two Exploited Root RCE Bugs

erroneo.us Security Desk — Mon, 14 Sep 2026 00:00:00 -0700

Verdict: Act now. Every on-premises Secure Email Gateway below 15.5.5-014 or 16.5.0-780 can be rooted by an email and both bugs are exploited: upgrade now, and check for compromise before and after, because attackers can wipe local evidence.

Who must act: Anyone running physical or virtual Cisco Secure Email Gateway on AsyncOS before 15.5.5-014, 16.0.x, or 16.5 before 16.5.0-780, including teams that moved to 16.0.4-302, which fixes only CVE-2026-76461.
Who can relax: Secure Email and Web Manager and Secure Web Appliance are not affected by these two CVEs, and Cisco has already upgraded Secure Email Cloud devices (but contacted cloud customers must rotate credentials).

List every gateway and cluster member and its AsyncOS release (version at the CLI).
Before upgrading, run Cisco's IOC checks on every appliance; on virtual appliances, collect forensic data first.
Upgrade to 16.5.0-780, or at minimum 15.5.5-014 (CLI: upgrade, then DOWNLOADINSTALL); 16.0 users must migrate.
Run contentscannerstatus and, if below 25.3.0.5525, run contentscannerupdate and enable automatic service updates.
If indicators are found: open a TAC case (physical) or redeploy a fresh VM on a fixed release without importing the old config (virtual), rotate credentials and keys, and restore every member of an affected cluster.
Keep management off the internet, separate mail and management interfaces, disable HTTP/FTP and forward logs to an external server.
Upgrade Secure Email and Web Manager to 15.5.5-006 or 16.5.0-429 for the related hardening release.

What happened

On September 14, 2026, Cisco published cisco-sa-esa-inj-2bLVGmhX for CVE-2026-76461, a SQL injection (CWE-89) in the email parsing logic of AsyncOS for Cisco Secure Email Gateway. An unauthenticated attacker only has to send a crafted message containing SQL statements through the gateway to run commands as root. Cisco rates it CVSS 3.1 9.8 and says it affects physical and virtual appliances "regardless of device configuration." The bug surfaced during a TAC support case, and Cisco PSIRT learned of active exploitation in September 2026. CISA added it to the KEV catalog the same day.

Cisco also shipped a hardening release that day for internally found flaws, including CVE-2026-76440, a group of path traversal issues. On October 14, Cisco published cisco-sa-esa-afw-zqYJkjxp for CVE-2026-76519, a relative path traversal (CWE-23) in the Advanced Malware Protection (AMP) file reputation feature. A crafted attachment lets an unauthenticated attacker write arbitrary files and run commands as root. It is also rated 9.8, PSIRT learned of exploitation in October, and it entered KEV the same day. SecurityWeek reports that its fix shipped in the September releases under CVE-2026-76440.

Cisco has not attributed either campaign or said how many appliances were hit, and we found no Talos analysis as of October 21, 2026. The Sophos Counter Threat Unit flagged CVE-2026-76461 but published no indicators.

Who is affected

On-premises Secure Email Gateway, physical or virtual, on AsyncOS below the fixed releases (CVE record, NVD):

CVE-2026-76461: every configuration. Fixed in 15.5.5-014 (15.5 and earlier), 16.0.4-302 and 16.5.0-780.
CVE-2026-76519: only when File Reputation is enabled and assigned to a mail policy and Content Scanner Tools is older than 25.3.0.5525. Fixed in 15.5.5-014 and 16.5.0-780, or by updating Content Scanner Tools. There is no 16.0 fix.

Secure Email and Web Manager and Secure Web Appliance are not affected by either CVE, though the Manager is covered by the hardening release (15.5.5-006 or 16.5.0-429). Cisco says it has upgraded all Secure Email Cloud devices to 16.5.0-780 and contacted cloud customers where it saw malicious activity.

Do you really need to act?

Yes, if an on-premises gateway is not on 15.5.5-014 or 16.5.0-780. The attack surface is the gateway's core job, accepting mail from the internet. No login, no user click and, for CVE-2026-76461, no special feature is needed, and Cisco confirms both bugs are exploited. Any gateway with AMP file reputation on a mail policy meets the CVE-2026-76519 condition unless Content Scanner Tools is already current, so check rather than assume automatic updates covered you.

Patching is not the end of it. Root on a mail gateway exposes mail flow, stored credentials and the SSH keys cluster members use to trust each other, and Cisco warns attackers may hide or remove evidence. A gateway that sat on a vulnerable release in September or October should be checked with Cisco's indicators before and after upgrading. Teams that moved to 16.0.4-302 for the first bug are still exposed to the second.

What to do now

List every gateway and cluster member and its release (version at the CLI).
Run the checks below on each appliance before upgrading. On virtual appliances, collect forensic data first; Cisco notes that redeploying destroys configuration and logs.
Upgrade to 16.5.0-780 (Cisco's recommendation for anything earlier than 16.5) or at minimum 15.5.5-014: CLI upgrade, then DOWNLOADINSTALL, or System Administration > System Upgrade.
Run contentscannerstatus. If it is older than 25.3.0.5525, run contentscannerupdate and enable automatic service updates; this closes CVE-2026-76519 without a restart.
If you find indicators, open a TAC case for physical appliances. For virtual ones, deploy a fresh VM on a fixed release, rebuild the configuration without importing the old file, rotate credentials and keys, and restore every member of an affected cluster.
Apply Cisco's hardening advice: no internet access to management, separate mail and management interfaces, external log forwarding, HTTP and FTP disabled.

How to tell if you were hit

For CVE-2026-76461, Cisco suggests searching mail logs for SQL that shells out, for example grep -i "COPY.*TO PROGRAM" mail_logs on every cluster member; any match may indicate malicious activity. Cisco also lists Snort rules 67109-67110. For CVE-2026-76519, run grep "System Security" system_logs. "Suspected compromise indicator was found" means compromise; "Security scan did not complete" means contact TAC; "No compromise indicator was found" means none was detected. Because root-level attackers can scrub local logs, also check firewall and proxy logs for unexpected uploads from the gateway to external IPs or downloads from unknown hosts, as The Hacker News relays from Cisco.

Timeline

Sep 14, 2026 — Cisco publishes the CVE-2026-76461 advisory and the September hardening release (15.5.5-014, 16.0.4-302, 16.5.0-780). CISA adds CVE-2026-76461 to KEV.
Sep 17, 2026 — Cisco adds cluster guidance to the advisory; CISA deadline for CVE-2026-76461.
Oct 14, 2026 — Cisco publishes CVE-2026-76519 as exploited and links it from the hardening advisory. CISA adds it to KEV.
Oct 17, 2026 — CISA deadline for CVE-2026-76519.

Sources

Security digest: September 14, 2026

erroneo.us Security Desk — Mon, 14 Sep 2026 00:00:00 -0700

1 editorial brief, 1 known exploited (cisa kev) addition and 1 critical advisory.

Known exploited (CISA KEV)

CVE-2026-76461 Cisco Secure Email Gateway: Cisco Secure Email Gateway SQL Injection Vulnerability (due 2026-09-17)

Critical advisories

ESPHome Device Builder: Renamed auth env vars silently disable dashboard authentication on upgrade

Security digest: September 11, 2026

erroneo.us Security Desk — Fri, 11 Sep 2026 00:00:00 -0700

4 known exploited (cisa kev) additions and 4 critical advisories.

Known exploited (CISA KEV)

CVE-2026-85706 GitLab Community Edition and Enterprise Edition: GitLab Community Edition and Enterprise Edition Path Traversal Vulnerability (due 2026-09-14)
CVE-2026-84869 ConnectWise ScreenConnect: ConnectWise ScreenConnect Improper Privilege Management and Missing Authorization Vulnerability (due 2026-09-14)
CVE-2026-42018 JFrog Artifactory: JFrog Artifactory Improper Authentication Vulnerability (due 2026-09-25)
CVE-2026-42016 JFrog Artifactory: JFrog Artifactory Incorrect Authorization Vulnerability (due 2026-09-25)

Critical advisories

Act now: GitLab CVE-2026-85706: Unauthenticated File Read, Exploited

erroneo.us Security Desk — Thu, 10 Sep 2026 00:00:00 -0700

Verdict: Act now. Any unpatched self-managed GitLab 18.7 or later can have its configuration and secret keys read by anyone on the network, and CISA says it is being exploited; upgrade today and rotate secrets if you were exposed.

Who must act: Administrators of self-managed GitLab CE/EE 18.7 and later (Omnibus, source, Helm), above all instances reachable from the internet.
Who can relax: GitLab.com and GitLab Dedicated customers (GitLab patched those), and self-managed instances still on versions before 18.7, which are outside the affected range.

Check your version (Admin > Overview, or /help) and upgrade to 19.3.2, 19.2.6, 19.1.8, 19.0.9 or 18.11.12 or later.
If you cannot upgrade immediately, remove internet exposure of the instance until you can.
Search api_json.log for unauthenticated POSTs to repository commits or files APIs carrying a file.path parameter.
If an exposed instance ran a vulnerable version, rotate gitlab-secrets.json / secrets.yml material, database, object storage, SMTP and LDAP credentials, and CI/CD secrets.
Deploy GitLab's published LFI detections in your SIEM.

What happened

On September 10, 2026 GitLab shipped a critical patch release (19.3.2, 19.2.6, 19.1.8) whose top fix is CVE-2026-85706. The bug is a path traversal in the repository commits API. GitLab's description: "an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement." GitLab scores it CVSS 3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). A HackerOne researcher, s3ntago, reported it.

CISA added it to the KEV catalog on September 11, one day after the patch, with a federal due date of September 14. CISA's enrichment in the CVE record marks exploitation as active and the attack as automatable. On September 23 GitLab backported the fix to 19.0.9 and 18.11.12.

GitLab's security team published detection notes describing the mechanism. On multipart uploads, Workhorse passes Rails a file.path parameter. An attacker sends an empty file part with a file.path that points at a file on the server, so Rails reads that host file instead of uploaded bytes. The notes say the parameter is reached mainly through POST /api/v4/projects/:id/repository/commits and the repository files API. They add that "public exploits defeat route sanitization with a trailing-slash bypass and percent-encoding."

Who is affected

Self-managed GitLab CE and EE from 18.7 onward is affected, covering every deployment type: Omnibus, source and Helm. Vulnerable ranges are 18.7 to before 18.11.12, 19.0 to before 19.0.9, 19.1 to before 19.1.8, 19.2 to before 19.2.6, and 19.3 to before 19.3.2. GitLab.com and GitLab Dedicated were already patched, so customers there have nothing to do.

Do you really need to act?

Yes, if you run GitLab yourself on an affected version. This is about as bad as a "file read" gets:

No authentication is needed. CISA rates it automatable and confirms exploitation.
The prime targets are gitlab.yml, secrets.yml, database.yml and gitlab-secrets.json. GitLab's own detection notes say these hold the Rails secret key base and the encryption keys used for sessions, tokens, stored CI/CD variables and 2FA, plus database, object storage, SMTP and LDAP credentials. "A confirmed read is therefore a credential exposure, not merely an information disclosure."
With the secret key base, an attacker can forge sessions and decrypt CI/CD variables. That reaches your cloud accounts and deployment pipelines.

Instances only reachable on a private network carry less risk but should still be patched promptly. Versions before 18.7 are not in the affected range.

What to do now

Check the version (sudo gitlab-rake gitlab:env:info on Omnibus, or the Help page) and upgrade to 19.3.2, 19.2.6, 19.1.8, 19.0.9 or 18.11.12 or later (sudo apt-get install gitlab-ee= or your Helm chart bump).
If you can't upgrade today, take the instance off the internet until you can.
Hunt in api_json.log as described below.
If an internet-exposed instance ran a vulnerable version after September 10, plan for secret rotation: regenerate secrets in gitlab-secrets.json following GitLab's procedures, rotate database, object-storage, SMTP and LDAP credentials, rotate CI/CD variables that hold cloud or deploy keys, and invalidate active sessions and tokens.

How to tell if you were hit

GitLab's detections look in api_json.log for unauthenticated requests (an ip/ client with no meta.user) to the commits or files APIs whose params contain an empty file part and a file.path pointing at config or secret files. GitLab published three rules: "GitLab LFI attempt reading gitlab.yml", "GitLab LFI via metadata.path parameter" and "GitLab LFI file path attempt". Widen your search to other host paths such as /etc/passwd, /proc/self/, SSH keys and .env files. Rejected attempts (status 400) are still worth logging. A successful response to such a request means you should rotate secrets. Afterwards, watch for unfamiliar sessions, new personal access tokens and odd access to object storage or the database.

Timeline

Sep 10, 2026 — GitLab releases 19.3.2, 19.2.6 and 19.1.8 with the fix.
Sep 11, 2026 — CISA adds CVE-2026-85706 to KEV, with a federal due date of Sep 14.
Sep 12, 2026 — The CVE record is published (NVD).
Sep 23, 2026 — GitLab backports the fix to 19.0.9 and 18.11.12.

Sources

Security digest: September 10, 2026

erroneo.us Security Desk — Thu, 10 Sep 2026 00:00:00 -0700

1 editorial brief, 2 known exploited (cisa kev) additions and 4 critical advisories.

Known exploited (CISA KEV)

CVE-2026-86060 MikroTik RouterOS: MikroTik RouterOS Improper Neutralization of Argument Delimiters in a Command Vulnerability (due 2026-09-13)
CVE-2026-67277 MikroTik RouterOS: MikroTik RouterOS Missing Authentication for Critical Function Vulnerability (due 2026-09-13)

Critical advisories

Act now: Check Point: Exploited VPN Gateway and Management RCEs

erroneo.us Security Desk — Wed, 09 Sep 2026 00:00:00 -0700

Verdict: Act now. Check Point shops should patch both gateways and management servers now: each flaw is unauthenticated RCE, both are exploited, and fixing one tier does not fix the other.

Who must act: Anyone running Check Point Security Gateways or Spark firewalls with Remote Access VPN or certificate-based Site-to-Site VPN, and anyone running on-prem Security Management, Multi-Domain, Log or SmartEvent servers.
Who can relax: Smart-1 Cloud customers (already fixed for the management bug), R82.20 gateways (not affected by the VPN bug), gateways that only use pre-shared-key Site-to-Site VPN with no Remote Access VPN, and non-Check Point shops.

Inventory every gateway, Spark appliance and management, log and SmartEvent server, with version and Jumbo Hotfix take.
Patch gateways with LivePatch Take 26 or the fixed Jumbo Hotfix, then confirm with cplp list that CVE-2026-85102 and CVE-2026-85103 are covered.
Update Spark firewalls to R82.00.10 Build 2325 or R81.10.17 Build 4968.
Patch management, log and SmartEvent servers separately (Security Hotfix or Jumbo R82.20 Take 10, R82.10 Take 45, R82 Take 127, R81.20 Take 170, R81.10 Take 192); LivePatch does not fix CVE-2026-93616.
Allow TCP/19009 and other management access only from trusted IPs, and restrict Trusted Clients in SmartConsole.
If gateway patching must wait, replace VPN implied rules with explicit rules limiting UDP/500 and UDP/4500 (and TCP/443/80 for Remote Access) to known peers or client ranges.

What happened

Check Point customers have two separate exploited, unauthenticated code-execution bugs to fix, one on each tier of the product.

CVE-2026-85102 (gateways). On September 9, 2026, Check Point shipped fixes for "improper validation of certificate data during VPN negotiation" that "may allow an unauthenticated remote attacker to execute arbitrary code on the Security Gateway" (sk1000117, CVSS 9.8). BleepingComputer reported the Dutch NCSC's warning that exploitation was imminent, and described a companion bug, CVE-2026-85103, as a heap overflow in the VPN certificate ASN.1 decoder. Check Point later updated its advisory to say the flaw "is actively exploited on Spark Firewalls as of September 12, 2026," with attempts coming from VPN services and proxies.

CVE-2026-93616 (management). sk1000171 describes a directory traversal and file upload flaw that lets an unauthenticated attacker upload and run scripts on the Management Server (CVSS 9.8). Check Point says it "is exploited in the Wild" and that it is aware of "a handful of customers who have been attacked." According to BleepingComputer, Check Point says exploitation as a zero-day dates back to July 23. CISA added both CVEs to the KEV catalog on September 22 (CVE-2026-85102, CVE-2026-93616) with a federal deadline of September 25.

Who is affected

Gateway bug: Security Gateways and Spark firewalls on R81.20, R82, R82.10, R81.10.x and R82.00.x, plus end-of-support R80 through R81.10, that run Remote Access VPN or Site-to-Site VPN with certificate authentication. DAIP and Large Scale VPN communities turn certificate authentication on. Gateways that only take part in pre-shared-key communities are not vulnerable, and R82.20 is not affected. The CVE record lists R82.10 Take 43, R82 Take 125 and R81.20 Take 165 or below as affected.

Management bug: Security Management, Multi-Domain Management, Log Server, Multi-Domain Log Server and SmartEvent on R82.20 without a Jumbo, R82.10 Take 44 or lower, R82 Take 126 or lower, R81.20 Take 166 or lower, R81.10 Take 190 or lower, and R80 through R81 (CVE record). Smart-1 Cloud is already fixed. Firewall appliances and Spark are not affected.

Do you really need to act?

If you run Check Point, yes. The VPN listener faces the internet by design. The management server is often reachable from more places than it should be, and owning it means owning policy for every gateway it manages. One detail traps teams: a management server on R82.10 Take 44, the gateway fix level, is still vulnerable to CVE-2026-93616, which needs Take 45. Check Point also says LivePatch does not cover the management bug and will not, so it needs a real hotfix install. Shops that use Check Point only with pre-shared-key site-to-site tunnels and no remote-access VPN have a narrower gateway risk, but still need the management fix.

What to do now

Inventory gateways, Spark units and management, log and SmartEvent servers by version and Jumbo take.
Gateways: install LivePatch Take 26 or the fixed Jumbo Hotfix. In Expert mode, run cpinfo -y CPupdates and cplp list (g_all cplp list on Scalable Platform) and confirm CVE-2026-85102 and CVE-2026-85103 appear. Earlier offline LivePatch packages need Take 26 for full coverage.
Spark: update to R82.00.10 Build 2325 or R81.10.17 Build 4968.
Management tier: install the R82.20 Security Hotfix (no reboot) or Jumbo R82.20 Take 10, R82.10 Take 45, R82 Take 127, R81.20 Take 170 or R81.10 Take 192.
Allow TCP/19009 only from trusted IPs, and restrict Trusted Clients under Manage & Settings > Permissions & Administrators.
If gateways cannot be patched yet, disable the VPN implied rules and allow UDP/500 and UDP/4500 (plus TCP/443 and TCP/80 for Remote Access) only from known peers or client ranges. Check Point notes this does not apply to locally managed Spark.

How to tell if you were hit

On gateways, search logs from September 12 onward for product "Mobile Access" with actions "Log In" and "Certificate," especially certificate subjects CN=vpn, CN=vpn-user or CN=vpnuser with OU=users,O=global. Check Point says the list is not exhaustive. Follow up on unknown users or source IPs, and on internal scanning that comes after a login. On each management, log and SmartEvent server, grep $MDS_FWDIR/log/cpm.elg* for login requests with usernames over 1,000 characters, and look for matching FWM or MDS core dumps in /var/log/dump/usermode/. Also look for version paths or uploads containing traversal sequences aimed at CPupgrade-tools. Check Point says a match means a possible attempt, not confirmed compromise.

Timeline

Jul 23, 2026 — Zero-day exploitation of CVE-2026-93616 begins, per Check Point via BleepingComputer.
Sep 9, 2026 — Check Point releases fixes for CVE-2026-85102 and CVE-2026-85103.
Sep 10, 2026 — The Dutch NCSC warns that exploitation is imminent.
Sep 12, 2026 — Exploitation attempts against Spark customers begin.
Sep 22, 2026 — The CVE-2026-93616 record is published. CISA adds both CVEs to KEV.

Sources

Security digest: September 9, 2026

erroneo.us Security Desk — Wed, 09 Sep 2026 00:00:00 -0700

1 editorial brief, 4 known exploited (cisa kev) additions and 1 critical advisory.

Known exploited (CISA KEV)

CVE-2026-87491 Google Chromium V8: Google Chromium V8 Out of Bounds Write Vulnerability (due 2026-09-23)
CVE-2026-20079 Cisco Secure Firewall Management Center (FMC) and Security Cloud Control (SCC) Firewall Management: Cisco Firewall Management Center Authentication Bypass Using an Alternate Path or Channel Vulnerability (due 2026-09-12)
CVE-2026-19490 Citrix NetScaler: Citrix NetScaler Authentication Bypass Using an Alternate Path or Channel Vulnerability (due 2026-09-12)
CVE-2025-25249 Fortinet Multiple Products: Fortinet Multiple Products Heap-based Buffer Overflow Vulnerability (due 2026-09-12)

Critical advisories

Apache FreeMarker template loading mechanism vulnerable to path traversal

Patch this week: Windows Zero-Days: Update Stack and ALPC EoP (Sep 2026)

erroneo.us Security Desk — Tue, 08 Sep 2026 00:00:00 -0700

Verdict: Patch this week. Make sure every Windows machine has the September 2026 or a later cumulative update; both bugs are exploited, but an attacker needs code running on the box first.

Who must act: Anyone with Windows 10, Windows 11 or Windows Server 2012 through 2025 machines that have not installed the September 8, 2026 or a later cumulative update, starting with desktops and multi-user servers.
Who can relax: Fleets already on September or October 2026 updates, and Linux or macOS hosts; neither bug can be triggered remotely without prior code execution.

Check the OS build on every Windows machine and compare it with the fixed build for its version.
Install the September 2026 or any later cumulative update (October's is fine) on stragglers, then reboot.
Patch Remote Desktop hosts, jump boxes and shared build agents first, since any logged-in user could become SYSTEM.
Find Windows machines that no longer receive monthly security updates and retire or isolate them.
Review EDR alerts from before patching for privilege escalation from user sessions to SYSTEM.

What happened

On September 8, 2026, Microsoft's monthly security release fixed two Windows privilege-escalation bugs that attackers were already exploiting. CVE-2026-81963 is a link-following flaw (CWE-59) in the Windows Update Stack. CVE-2026-85880 is a heap-based buffer overflow (CWE-122) in Advanced Local Procedure Call (ALPC), the Windows mechanism processes use to message each other locally. Either one lets an attacker who already runs code with low privileges become SYSTEM. Microsoft rates both Important, scores both CVSS 3.1 7.8, and marks both "Exploitation Detected". CISA added both to the Known Exploited Vulnerabilities catalog the same day and gave federal agencies until September 22.

Microsoft has not described the attacks. Its acknowledgments credit the Microsoft Threat Intelligence Center (MSTIC) and outside researchers for the Update Stack bug, and Proofpoint researchers and Volexity for the ALPC bug. For CVE-2026-85880, Microsoft's FAQ says an attacker "who can execute code in a low-privilege AppContainer could exploit this vulnerability locally to escape the sandbox." That makes it a natural second stage after a browser or document exploit.

Who is affected

According to Microsoft's update guide, the two bugs split cleanly across Windows generations. Every supported release needed one fix or the other.

CVE-2026-81963 (Update Stack): Windows 11 23H2, 24H2, 25H2 and 26H1, and Windows Server 2025. Fixed by KB5124008 (24H2 build 26100.9445, 25H2 26200.9445), KB5122880 (23H2, 22631.7582), KB5124012 (26H1, 28000.2954) and KB5122871 (Server 2025, 26100.33438).
CVE-2026-85880 (ALPC): Windows 10 1607, 1809, 21H2 and 22H2, and Windows Server 2012, 2012 R2, 2016, 2019 and 2022. Fixed by KB5122878 (Windows 10 21H2/22H2, 19044/19045.7725), KB5122876 (1809 and Server 2019, 17763.9245), KB5123099 (1607 and Server 2016, 14393.9512), KB5122882 (Server 2022, 20348.5622), and the monthly rollups KB5123066 (2012 R2) and KB5123065 (2012).

The CVE records define the fix by build number, so any later cumulative update, including October 2026's, also covers both bugs.

Do you really need to act?

Yes, but this is fleet hygiene rather than an emergency, and most managed fleets finished it in September. Both bugs are local. The attacker first needs code on the machine, through phishing, a malicious download, a stolen login or another exploit. Local privilege escalation is still what turns one compromised user into full control of a host: security tools switched off, credentials dumped, lateral movement. Dustin Childs of the Zero Day Initiative told Help Net Security he doubts the automatic update process itself is compromised. He thinks the Update Stack bug is more likely paired with a code-execution bug to spread malware or ransomware. Tenable counts seven Update Stack privilege-escalation bugs patched since 2022, and this is the first exploited as a zero-day. It calls the ALPC bug the first ALPC fix on a Patch Tuesday in more than three years, and the second ALPC flaw exploited as a zero-day since CVE-2023-21674.

Desktops and laptops, including developer workstations, are the likeliest targets, because people open files and browse on them. Confirm the update is installed.
Multi-user servers such as Remote Desktop hosts, jump boxes and shared build agents come next. Anyone who can log in could become SYSTEM.
Single-purpose servers with no untrusted users or files: patch on your normal cycle.
Windows machines that no longer receive monthly security updates did not get either fix and will not.
Linux and macOS are not affected.

What to do now

Check the build. Run winver, or in PowerShell Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select CurrentBuild, UBR, and compare with the fixed build above (for example 26100 and 9445 or higher on Windows 11 24H2).
Do not rely on Get-HotFix -Id KB5124008 alone. A newer cumulative update replaces the September KB, so a higher build number also counts. For fleets, use your Intune, WSUS or Configuration Manager compliance reports.
Install the latest cumulative update on stragglers and reboot. The fix does not take effect until the restart.
Do Remote Desktop hosts, jump boxes and CI agents that run untrusted code first.
Retire or isolate Windows hosts that are out of security support.

How to tell if you were hit

As of Oct 21, 2026, Microsoft, Proofpoint and Volexity have not published indicators for these bugs, so there is no signature to search for. Hunt for the general pattern of local privilege escalation in EDR telemetry: SYSTEM processes whose parent chain leads back to a user session, a browser or an Office app; new services or scheduled tasks created right after a user opened a file; and, for the Update Stack bug, junctions or symbolic links created by non-admin accounts in folders that Windows Update components write to. If a host was compromised at user level before it was patched, treat it as fully compromised. Reimage it and rotate the credentials it held.

Timeline

Sep 8, 2026 — Microsoft releases fixes and marks both bugs as exploited. CISA adds both to KEV.
Sep 16, 2026 — Microsoft corrects the CVSS temporal exploit-maturity setting for CVE-2026-85880 (informational change only).
Sep 22, 2026 — CISA's remediation deadline for federal agencies.
Oct 7, 2026 — Latest revision of the CVE-2026-81963 advisory (acknowledgment update only).

Sources

Security digest: September 8, 2026

erroneo.us Security Desk — Tue, 08 Sep 2026 00:00:00 -0700

1 editorial brief, 4 known exploited (cisa kev) additions and 14 critical advisories.

Known exploited (CISA KEV)

CVE-2026-86218 N-able N-central: N-able N-central Static Code Injection Vulnerability (due 2026-09-11)
CVE-2026-85880 Microsoft Windows: Microsoft Windows Heap-Based Buffer Overflow Vulnerability (due 2026-09-22)
CVE-2026-81963 Microsoft Windows: Microsoft Windows Link Following Vulnerability (due 2026-09-22)
CVE-2026-75650 Adobe Commerce and Magento: Adobe Commerce and Magento Improper Neutralization of Special Elements Used in a Template Engine Vulnerability (due 2026-09-11)

Critical advisories

Act now: Magento StyleSmuggler CVE-2026-75650: Exploited Pre-Auth RCE

erroneo.us Security Desk — Mon, 07 Sep 2026 00:00:00 -0700

Verdict: Act now. Any self-run Magento or Adobe Commerce store without the September hotfix should be presumed compromised: patch, then scan, then rotate the encryption key and every credential it protects, and add the October fix for the follow-on BlockStrap bug.

Who must act: Every merchant, agency and host running Adobe Commerce 2.4.4-2.4.9, Commerce B2B 1.3.3-1.5.3 or Magento Open Source 2.4.6-2.4.9, including Adobe Commerce on cloud infrastructure, plus anyone still on unsupported 2.4.3 or older.
Who can relax: Stores on hosted SaaS platforms such as Shopify or BigCommerce, and teams with no Magento code anywhere in production.

Check whether the hotfix is present: vendor/bin/magento-patches -n status | grep "39341\|Status"
Apply the VULN-39341 hotfix for your patch level, then the October 2026 release or isolated patch for CVE-2026-103849; keep both.
Scan the store for StyleSmuggler implants, web shells and skimmers before declaring it clean; the hotfix does not remove them.
Rotate the Magento encryption key and every credential it protected (admin, integration and OAuth tokens, payment gateway keys, database, SSH and deploy keys) at the source.
Put WAF protection in front of the store as defense in depth, and plan an upgrade off any 2.4.3-or-older install, which has no Adobe fix.

What happened

On September 7, 2026, Adobe published APSB26-146, a priority 1 hotfix for CVE-2026-75650. The flaw is a template-engine injection (CWE-1336) in Adobe Commerce and Magento Open Source. Adobe scores it CVSS 3.1 10.0, says no authentication is required, and states that it "is aware of CVE-2026-75650 being exploited in the wild."

Sansec, which named the bug StyleSmuggler, had gone public two days earlier. It saw unsuccessful probes on August 23 and the first confirmed compromise at 22:20 UTC on September 4. The attack has two stages. First, the attacker plants PHP in a file Magento writes itself. One variant puts the code in a request to /paypal/transparent/response/, which Magento logs under var/report/. Second, a POST /graphql request abuses a styles parameter so the template engine includes that file while rendering the "Payment Transaction Failed Reminder" email. Neither stage needs a login, an admin session or a form key.

CISA added the CVE to its KEV catalog on September 8. On October 13, APSB26-153 fixed CVE-2026-103849, another unauthenticated template-engine injection scored 10.0. Sansec calls it BlockStrap and says it "exposes a gap left by the StyleSmuggler fix." Adobe reports no known exploitation and rated the update priority 2. Sansec disputes that rating, per BleepingComputer.

Who is affected

Adobe lists these builds as affected, in each case the "2026-aug" release and earlier:

Adobe Commerce 2.4.4 through 2.4.9
Commerce B2B 1.3.3 through 1.5.3
Magento Open Source 2.4.6 through 2.4.9

The fix is a patch file, VULN-39341, not a new version number. Adobe's knowledge-base notice maps patch files to each patch level, and cloud merchants apply it too. Sansec reports that a store on 2.4.6-p15, with the July and August patches installed, was still hit. Adobe offers no patch for 2.2, 2.3 or 2.4.0 through 2.4.3. A community backport exists for those, but Sansec has not reviewed it.

Do you really need to act?

Yes, if you run Magento or Adobe Commerce yourself or through an agency. This is a pre-authentication RCE against the checkout stack, and attackers used it for days before any patch existed. Sansec watched the payloads change several times a day.

Attackers dropped a Rust Linux backdoor that disguises its command traffic as NTP packets. The Hacker News also reports PHP droppers that install web shells, and Sansec found payment skimmers.

Patching is necessary but not enough. Adobe and Sansec both say the hotfix does not clean a store that was already compromised. Rotating the encryption key alone also does not invalidate secrets an attacker has already read. Shopify and BigCommerce merchants are unaffected.

What to do now

Check: vendor/bin/magento-patches -n status | grep "39341\|Status"
Apply the VULN-39341 patch for your version (VULN-39341-composer-patches.zip from repo.magento.com, or the per-version file Adobe lists). Then install the 2026-oct release or Adobe's isolated BlockStrap patch. Keep both fixes in place.
Scan for compromise (next section) before you call the store clean.
Follow Adobe's procedure: enable maintenance mode, stop cron, then rotate the encryption key. Next, rotate admin passwords, integration and OAuth tokens, payment gateway keys, database credentials, SSH and deploy keys, and extension API keys, each at its source.
Keep WAF rules on as an extra layer, not a fix. Sansec notes that Cloudflare and Imperva shipped rules on September 10 and that Commerce Cloud has a Fastly virtual patch. Move any install on 2.4.3 or older to a supported release.

How to tell if you were hit

From the Magento root, run Sansec's checks: grep -ril 'x_trace_' var/report/ and find -L pub/media -type f -name '*.php'. Run ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd' and look for web-user processes such as [kworker/u:8:0]. Inspect the cron spool directly for entries pointing at ~/.local/share/.gvfsd/ or ~/.cache/fontconfig/. One implant build relaunches without cron, so an empty crontab proves nothing. Search var/log/exception.log with grep -aF for Laminas\Loader\Exception\InvalidArgumentException, and check core_config_data at design/head/includes for injected loaders. On the network, UDP/123 traffic to hosts such as ntp.timesync.to is a strong signal.

Timeline

Aug 23, 2026 — Sansec sees unsuccessful probes.
Sep 4, 2026 — The first confirmed compromise occurs at 22:20 UTC.
Sep 5, 2026 — Sansec publishes StyleSmuggler while the bug is still unpatched.
Sep 7, 2026 — Adobe releases APSB26-146 and the VULN-39341 hotfix.
Sep 8, 2026 — CISA adds CVE-2026-75650 to KEV, with a September 11 deadline.
Oct 13, 2026 — Adobe releases APSB26-153, fixing BlockStrap (CVE-2026-103849).
Oct 16, 2026 — Sansec reports no BlockStrap attacks yet and urges merchants to keep both fixes in place.

Sources

Security digest: September 7, 2026

erroneo.us Security Desk — Mon, 07 Sep 2026 00:00:00 -0700

1 editorial brief and 1 critical advisory.

Critical advisories

@sap/cds-mtx: Credential disclosure in multitenant applications using SAP Cloud Application Programming Model (CAP)

Security digest: September 4, 2026

erroneo.us Security Desk — Fri, 04 Sep 2026 00:00:00 -0700

1 known exploited (cisa kev) addition and 2 critical advisories.

Known exploited (CISA KEV)

CVE-2026-85046 Google Chromium V8: Google Chromium V8 Type Confusion Vulnerability (due 2026-09-18)

Critical advisories

Act now: ScreenConnect CVE-2026-84869: Guest-to-Host File Execution

erroneo.us Security Desk — Thu, 03 Sep 2026 00:00:00 -0700

Verdict: Act now. If your technicians use a ScreenConnect client older than 26.6.5, a compromised machine they connect to can run code on theirs; upgrade on-premises servers and reinstall host clients now.

Who must act: MSPs, help desks and IT teams using on-premises ScreenConnect below 26.6.5, or using any ScreenConnect deployment whose technicians still run old host clients, especially when supporting untrusted or consumer endpoints.
Who can relax: ScreenConnect Cloud customers who have already reinstalled host clients and updated access agents after ConnectWise's automatic 26.6.5 upgrade; the ScreenConnect server itself is not affected.

Upgrade on-premises ScreenConnect servers to 26.6.5 or later; renew maintenance first if your license has lapsed.
Reinstall host clients on every technician machine and update access agents, on Cloud and on-premises alike.
Until that is done, remove the TransferFiles permission (TransferFilesInSession on older versions) from every role under Administration > Security > Roles.
Review ScreenConnect users and roles, remove anyone unrecognized, change passwords and enforce MFA.
Reimage any technician or endpoint machine that shows the indicators below, rather than cleaning it in place.

What happened

On September 3, 2026, ConnectWise posted a Guest File Transfer Advisory. It said it had "identified an issue affecting file transfer behavior" in ScreenConnect Remote Access Support and Access sessions, on both Cloud and on-premises, and gave an interim workaround: remove the TransferFiles permission. On September 8 it published the ScreenConnect 26.6.5 security bulletin and assigned CVE-2026-84869. The CVE record is titled "Guest-to-Host File Execution via File-Transfer Actions." It says a condition in the ScreenConnect client "may allow files to be transferred and executed through an active remote session without authorization or Host confirmation in certain circumstances." ConnectWise's disclosure adds that the files can run on the host system, "including with elevated privileges."

In ScreenConnect terms, the host is the technician and the guest is the machine being supported. The flaw runs in the unusual direction, from guest to technician. ConnectWise scores it CVSS 3.1 9.9 (AV:N/AC:L/PR:L/UI:N/S:C) with CWE-862 and CWE-269, and gave it Priority 1, which means install within days. The CVE record notes that "ScreenConnect servers are not impacted." CISA added it to the KEV catalog on September 11, with a September 14 deadline.

Who is affected

All ScreenConnect client versions before 26.6.5 are affected. ConnectWise upgraded Cloud servers automatically, but on both Cloud and on-premises it says host clients must be reinstalled and access agents updated after the upgrade. A patched server alone does not protect a technician who is still running an old client. On-premises partners need a license under active maintenance to download 26.6.5. Automate partners with Assurance can get it through Automate Product Updates.

Do you really need to act?

Yes, if your technicians connect to machines you do not fully control. Huntress tracked incidents on August 20 and 24 in which victims installed rogue ScreenConnect clients after a tech-support scam, a phishing MSI or a fake Geek Squad refund page. The modified clients ran four VBScripts (1.vbs to 4.vbs) that installed hidden ScreenConnect backdoors, a wstunnel tunnel and an XMRig miner. They also watched for new host connections and pushed the same scripts as a file-transfer "run" action, so the connecting machine ran them too. Huntress called the spread "worm-like." Huntress's John Hammond told Help Net Security that Huntress believes attackers used this CVE. ConnectWise had not confirmed that link as of September 7, and its bulletin shares no further detail.

The precondition is a malicious or compromised guest, which keeps this from being a mass internet scan-and-own bug. But technician laptops are high-value machines, and help desks connect to unknown endpoints every day. ScreenConnect has a history of exploitation. BleepingComputer counts four ScreenConnect issues in KEV since 2024, two of them used in ransomware attacks. This is a different flaw from the 2024 server authentication bypass, CVE-2024-1709.

What to do now

On-premises: upgrade the server to 26.6.5 or later and confirm the running version.
Reinstall the host client on every technician machine and update access agents. Do this on Cloud too.
Until clients are updated, open Administration > Security > Roles and untick TransferFiles (TransferFilesInSession on older versions) for every role. ConnectWise says this needs no upgrade but is not a substitute for one.
Follow the bulletin's post-patch steps: remove unrecognized users, review roles, change passwords and enable MFA.

How to tell if you were hit

Search the ScreenConnect audit log for RunFiles or RanFiles events with Process: Guest, especially for 1.vbs through 4.vbs. Huntress treats any such entry as immediately suspicious, because filenames can change. On Windows, check reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v WindowsServiceHost, and look for wscript.exe children of ScreenConnect processes and for %TEMP%\value.txt, map.txt or runner.ps1. Huntress also lists the rogue client ID 7a4d7d66502d4260 and the tunnel endpoint homehub.opik[.]net. Reimage affected machines from known-good media, then rotate any credentials stored on technician machines.

Timeline

Aug 20, 2026 — Huntress handles the first two incidents involving rogue ScreenConnect clients and VBScript chains; a third follows on August 24.
Sep 3, 2026 — ConnectWise publishes the Guest File Transfer Advisory with the TransferFiles workaround.
Sep 8, 2026 — ScreenConnect 26.6.5 and CVE-2026-84869 are published; Cloud servers are upgraded.
Sep 11, 2026 — CISA adds the CVE to KEV, due September 14.

Sources

Act now: MikroTrick: Exploited MikroTik RouterOS SSH Takeover Chain

erroneo.us Security Desk — Thu, 03 Sep 2026 00:00:00 -0700

Verdict: Act now. If you run MikroTik routers, upgrade them now and check for an 'ops' admin account; an unauthenticated SSH chain to full admin was exploited a day before patches shipped.

Who must act: Anyone running RouterOS 6 or 7, most urgently where SSH, WebFig or the bandwidth-test server is reachable from the internet or another untrusted network.
Who can relax: Teams with no MikroTik gear; devices whose management services are reachable only over a management VPN still need the upgrade but are not on the reported attack path.

Inventory every RouterOS device, including cloud and lab instances, and record its version.
Upgrade to 7.24.3, 7.23.6 or 6.49.21 or later; devices moved to 7.24.2 or 7.23.4 in September need a second upgrade.
Restrict SSH, WebFig (www/www-ssl) and the bandwidth-test server to trusted management addresses or disable them; prefer a VPN for management.
Run /system/device-mode/print and check the log for a critical 'Flagged' entry after upgrading.
Review users, scripts, scheduler entries, proxies and tunnels for anything you did not create, starting with a full-privilege user named 'ops'.
If you find signs of compromise, preserve logs and config, factory reset, rebuild from a trusted configuration and rotate every secret on the device.

What happened

On September 3, 2026, MikroTik shipped RouterOS 7.24.2, 7.23.4 and 6.49.21 as "an important security update" and held back the details. The release notes mentioned only an SSH refactor and btest stability fixes. Two days later CERT Polska published the findings: six RouterOS bugs, two of which chain into what it calls MikroTrick. The chain gives full administrative control "without authentication" when SSH is reachable. CERT Polska says successful attacks began no later than September 2, a day before the patches.

Three of the six CVEs are in CISA's KEV catalog:

CVE-2026-67279 (CVSS 4.0 6.9): after a client-requested rekey, RouterOS SSH enters the connection protocol even though no login was attempted. The client can then open a session channel and send an exec request. Added to KEV September 25.
CVE-2026-86060 (CVSS 4.0 9.2): the SSH login helper accepts a username starting with a prohibited character. Bishop Fox explains that the username -2 makes the helper read its trusted identity from file descriptor 2, which the attacker controls. The helper then accepts a forged administrator record. Added to KEV September 10.
CVE-2026-67277 (CVSS 4.0 8.8): the bandwidth-test (btest) service accepts a related connection before authentication. That leaks uninitialized kernel memory and can restart the router. Added to KEV September 10.

The other three, which are not in KEV, are an SSH public-key check that skips the RSA exponent (CVE-2026-67276), an unauthenticated WebFig file read on 7.20 and newer (CVE-2026-67281), and RSA signature forgery against TLS and SSH host keys (CVE-2026-67278). The September builds only partly fixed CVE-2026-67278. MikroTik's updated advisory names 7.24.3 and 7.23.6 as the complete fix.

Who is affected

The KEV-listed bugs affect RouterOS 6.x before 6.49.21, 7.0 through 7.23.x before 7.23.4, and 7.24 before 7.24.2, according to CERT Polska's CVE list. Bishop Fox reproduced the full takeover on 7.x. On 6.49.20 the rekey bypass worked, but the chain did not produce an admin session. Patch 6.x anyway. CERT Polska's recommended minimums are 7.24.3 (stable), 7.23.6 (long-term) and 6.49.21.

Do you really need to act?

If you own RouterOS devices, yes. The precondition is a reachable SSH service. MikroTik says its default configurations block management services from the internet, so the main targets are routers where someone opened SSH. That happens often on ISP, branch-office and hosted routers. The attack needs no credentials, CISA rates it automatable, and it worked before any patch existed. The Hacker News notes that no authoritative count of compromised devices has been published. Bishop Fox found compromise artifacts on internet-facing routers during authorized testing.

A router whose SSH is reachable only over a management VPN is not on the reported attack path. It still runs the vulnerable code, so upgrade it this week. The incomplete CVE-2026-67278 fix means devices upgraded in September need a second upgrade.

What to do now

On each device, check the version with /system resource print.
Upgrade with /system package update check-for-updates then /system package update install, to 7.24.3, 7.23.6 or 6.49.21 or later.
Limit management services to trusted addresses, for example /ip service set ssh address=192.0.2.0/24, and do the same for www/www-ssl. Turn off the bandwidth-test server with /tool bandwidth-server set enabled=no if you do not use it. CERT Polska also advises against using /system ssh outbound from unpatched devices.
After upgrading, run /system/device-mode/print. Fixed releases scan for known traces of tampering at boot and set a "Flagged" marker. Do not clear it until you have investigated.
Review /user print, /system script print and /system scheduler print for anything you did not create.

How to tell if you were hit

CERT Polska lists log lines such as login failure for user -2 from via ssh followed by user added by ssh:-2@, a full-privilege user named ops, successful attacks from 82.192.72.4 and attempts from 103.102.31.18. Bishop Fox found a scheduled script that recreated a privileged account every day. It suggests objects with owner="0" as a hunting lead, with the caveat that legitimate objects can also show this. A missing indicator does not rule out compromise. If you find one, isolate the device, secure the logs and configuration, factory reset, and rebuild from a trusted configuration rather than a backup taken from the device. Then rotate every password, key and secret it held. Upgrading blocks new exploitation but does not remove existing access.

Timeline

Sep 2, 2026 — Earliest successful attacks seen by CERT Polska.
Sep 3, 2026 — MikroTik releases 7.24.2, 7.23.4 and 6.49.21 with no vulnerability details.
Sep 5, 2026 — CERT Polska publishes the six CVEs, the MikroTrick chain and indicators.
Sep 10, 2026 — CISA adds CVE-2026-86060 and CVE-2026-67277 to KEV.
Sep 17, 2026 — Bishop Fox publishes its analysis of the chain.
Sep 25, 2026 — CISA adds CVE-2026-67279 to KEV (NVD).
Oct 6, 2026 — MikroTik updates its advisory to list all six CVEs and names 7.24.3 and 7.23.6 as the complete fix.

Sources

Check exposure: Chrome V8 Zero-Days CVE-2026-85046 and CVE-2026-87491

erroneo.us Security Desk — Thu, 03 Sep 2026 00:00:00 -0700

Verdict: Check exposure. Both were exploited zero-days, but Chrome and Edge fixed them in early September and auto-update has had six weeks to deliver the fix; the job now is finding browsers that did not update, not a scramble.

Who must act: Admins of fleets where Chrome or Edge updates are pinned, deferred or broken, owners of kiosk and VDI images, and users of Chromium-based browsers whose vendor has not shipped a September 2026 or later V8 fix.
Who can relax: Chrome users on 153.0.8010.36 or later and Edge users on 153.0.4234.32 or later, which includes anyone whose browser auto-updated and relaunched since mid-September.

Open chrome://settings/help (or edge://settings/help), relaunch if an update is pending, and confirm Chrome is at 153.0.8010.36 or later.
In managed fleets, report browser versions and flag any endpoint below Chrome 153.0.8010.36 or Edge 153.0.4234.32.
Remove policies that pin Chrome or Edge to an old version or defer updates indefinitely, and use RelaunchNotification policies so updates actually apply.
Check Opera, Brave, Vivaldi and any other Chromium-based browser in use for a release that includes the September 2026 V8 fixes.
If you use Chrome Extended Stable, confirm your build carries both fixes, because its release notes do not list CVEs, or move those users to Stable.

What happened

On September 3, 2026, Google shipped Chrome 152.0.7977.82/.83 for Windows and Mac and 152.0.7977.82 for Linux, with 12 security fixes. One was CVE-2026-85046, a high-severity type confusion in V8, Chrome's JavaScript and WebAssembly engine. Google said it "is aware that an exploit for CVE-2026-85046 exists in the wild." Salvatore Gulizia (Serotav) reported the bug on August 4; Google's notes do not credit its Threat Analysis Group. His write-up places it in how the Maglev compiler inlines Array.prototype.sort. A comparator that calls fill() can change the array's element kind mid-sort and still pass a guard check. He says he chained it with an n-day sandbox escape and submitted it to v8CTF, Google's V8 exploit program.

On September 8, Google promoted Chrome 153 to Stable as 153.0.8010.36/.37 for Windows and Mac and 153.0.8010.36 for Linux, with 230 security fixes. Among them was CVE-2026-87491, a Medium-rated out-of-bounds write in V8. Jihyeon Jeong of Seoul National University's Compsec Lab reported it on August 6. Again, Google said an exploit "exists in the wild."

For both bugs, the records say a crafted HTML page lets a remote attacker "execute arbitrary code inside the sandbox." NVD shows CISA-ADP scores of CVSS 3.1 8.8 for both. CISA added CVE-2026-85046 to KEV on September 4 (due September 18) and CVE-2026-87491 on September 9 (due September 23). Google has not said who used either exploit, against whom, or what it was chained with. Help Net Security counted CVE-2026-87491 as the seventh exploited Chrome zero-day of 2026.

Who is affected

Chrome on Windows, Mac, Linux and Android below the fixed builds is affected. Chrome for Android got 152.0.7977.82 on September 3 and 153.0.8010.36 on September 8, with the same security fixes as desktop. ChromeOS Stable 152.0.7977.113 (September 8) lists CVE-2026-85046.

CISA notes that the bugs could affect other Chromium-based browsers, including Edge and Opera. Microsoft's Edge security release notes say Edge Stable 152.0.4191.62 (September 2) fixes CVE-2026-85046 and 152.0.4191.66 (September 4) fixes CVE-2026-87491. Microsoft's Security Update Guide, however, lists 153.0.4234.32, released September 10, as the fixed Edge build for CVE-2026-87491. Treat 153.0.4234.32 as the safe minimum.

Do you really need to act?

For most people, not anymore. These were real zero-days. In the days after each fix, anyone browsing on an old build could have been targeted just by loading a page. But Chrome and Edge update themselves, and a browser that has auto-updated and relaunched since mid-September has both fixes.

Exposure is now concentrated in a few places: fleets where an update policy pins or defers versions, machines where the update is downloaded but the browser never restarts, kiosk and VDI golden images, and Chromium forks that ship V8 fixes late. Code execution "inside the sandbox" usually needs a second bug to take over the device. That is a hurdle for attackers, not a guarantee, and exploited browser bugs are routinely paired with sandbox escapes.

What to do now

Check a single machine: open chrome://settings/help or edge://settings/help and relaunch. From a shell, use google-chrome --version on Linux, "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --version on macOS, or (Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion in PowerShell.
In managed fleets, pull browser versions from your MDM or EDR inventory and chase anything below Chrome 153.0.8010.36 or Edge 153.0.4234.32.
Remove version pins and long update deferrals, and set relaunch policies so downloaded updates actually apply.
Update other Chromium-based browsers and rebuild kiosk or VDI images that bundle an old browser.
If you use Extended Stable, confirm with Google that your build contains both fixes, since those release notes do not list CVEs, or move users to Stable.

How to tell if you were hit

Google has published no indicators, targets or delivery details, so after-the-fact detection is hard. First, find the machines that ran a vulnerable build in late August or early September, and note their users. For high-risk users on those machines, such as executives, admins and people in sensitive roles, review EDR telemetry from that window. Look for browser processes launching unexpected executables, new services, scheduled tasks or launch agents, and unusual outbound connections. If you find anything, reimage the device and rotate credentials and session tokens used in that browser.

Timeline

Aug 4, 2026 — Salvatore Gulizia reports CVE-2026-85046.
Aug 6, 2026 — Jihyeon Jeong reports CVE-2026-87491.
Sep 2, 2026 — Edge 152.0.4191.62 ships with the CVE-2026-85046 fix.
Sep 3, 2026 — Chrome 152.0.7977.82 is released for desktop and Android. Google confirms an in-the-wild exploit for CVE-2026-85046.
Sep 4, 2026 — CISA adds CVE-2026-85046 to KEV, and Edge 152.0.4191.66 is released.
Sep 8, 2026 — Chrome 153.0.8010.36 fixes CVE-2026-87491, with an in-the-wild exploit confirmed. ChromeOS 152.0.7977.113 is released.
Sep 9, 2026 — CISA adds CVE-2026-87491 to KEV.
Sep 10, 2026 — Edge 153.0.4234.32 is released.
Sep 18, 2026 — CISA deadline for CVE-2026-85046.
Sep 23, 2026 — CISA deadline for CVE-2026-87491.

Sources

Security digest: September 3, 2026

erroneo.us Security Desk — Thu, 03 Sep 2026 00:00:00 -0700

3 editorial briefs and 14 critical advisories.

Critical advisories

Patch this week: LiteLLM Proxy: Three Exploited Flaws in CISA KEV

erroneo.us Security Desk — Wed, 02 Sep 2026 00:00:00 -0700

Verdict: Patch this week. If you run a self-hosted LiteLLM Proxy older than 1.84.0, upgrade now and treat the provider keys it holds as possibly exposed; SDK-only users are not affected.

Who must act: Operators of self-hosted LiteLLM Proxy (AI gateway) deployments, especially any reachable from the internet or from broad internal networks, and anyone still using the default sk-1234 master key.
Who can relax: Projects that only import the litellm Python SDK as a client library and do not run the proxy server, and proxies already on 1.84.0 or later with a strong master key.

Upgrade the proxy to 1.84.0 or later (pin an exact version and verify hashes or image digest).
If you cannot upgrade, block /mcp/ and /mcp-rest/test/* at the reverse proxy and set general_settings.disable_error_logs: true.
Replace any default master key (sk-1234) and never run the proxy without a master key.
Do not expose the admin UI or management API to the internet; restrict to a VPN or allowlist.
Rotate provider API keys, virtual keys and the DATABASE_URL password if the proxy was exposed while vulnerable.
Review guardrails, pass-through endpoints and users for entries you did not create.

What happened

LiteLLM Proxy is a self-hosted "AI gateway" that holds an organization's upstream LLM provider keys and hands out virtual keys to apps and users. In 2026 it collected three entries in the CISA Known Exploited Vulnerabilities catalog. The most recent, added September 2, 2026, is CVE-2026-59822. In proxies older than 1.84.0, the MCP Streamable HTTP endpoint accepted any made-up Bearer token. A failed key check fell through to an OAuth2 passthrough path that substituted an empty auth object. Per the advisory (CVSS 4.0 8.8), that let an unauthenticated attacker list and call whatever MCP tools the proxy had configured, and reach the services behind them.

The two earlier KEV entries:

CVE-2026-42208 (CVSS 9.3, added to KEV May 8). An unauthenticated SQL injection through the Authorization header on ordinary routes such as /chat/completions, which exposes the proxy database and the credentials stored in it.
CVE-2026-42271 (added June 8). Lets any holder of a low-privilege key run OS commands through the MCP stdio "test connection" endpoints.

Both were fixed in 1.83.7. Wiz's research adds CVE-2026-59821, a guardrail sandbox escape fixed in 1.82.0. Wiz also reports that the default sk-1234 master key doubles as the JWT signing secret: 9.6% of 3,074 instances it scanned accepted that key, and 6.2% required no auth at all.

Who is affected

This affects only deployments that run the proxy server (litellm --config or the ghcr.io/berriai/litellm images) on a version below 1.84.0. Apps that import litellm as a client SDK do not expose these endpoints. The MCP bypass matters most where MCP servers are configured, because those tools often reach internal systems, databases or SaaS APIs.

Do you really need to act?

Yes, if you run the proxy and are behind. Exploitation is confirmed. Wiz saw CVE-2026-59822 exploited in its honeypots on July 7, 2026, and CISA set a September 16 remediation deadline for federal agencies. An AI gateway is a high-value target. One foothold yields a whole organization's provider keys, which attackers resell or burn on "LLMjacking." LiteLLM's own October 21 incident report says an unexpected user on an internally exposed LiteLLM deployment, possibly via "a recently patched vulnerability," was the likely starting point for the supply-chain compromise of release 1.107.0. Root cause is not confirmed as of October 21. The lesson stands either way: internal-only does not mean safe. If your proxy is on 1.84.0 or later, has a strong master key and an admin plane that is not publicly reachable, you have done the important work.

What to do now

Upgrade to 1.84.0 or later and pin an exact, verified version. Do not install 1.107.0, the malicious release from October 21. 1.106.2 was the last known-good release at that time.
If you can't upgrade today, block /mcp/ and /mcp-rest/test/* at your ingress, and set general_settings: disable_error_logs: true, which the 42208 advisory gives as a workaround.
Replace any default or weak LITELLM_MASTER_KEY, and make sure the proxy never runs without one.
Restrict the admin UI and management routes to a VPN or allowlist, and limit container egress, including to the cloud metadata service.
If the proxy was reachable while vulnerable, rotate the upstream provider keys, master and virtual keys, and the DATABASE_URL credentials.

How to tell if you were hit

Check the version with pip show litellm inside the running container. In access logs, look for:

MCP requests from unknown clients.
Calls to /mcp-rest/test/connection.
Odd quoting or SQL fragments in Authorization headers.

In LiteLLM itself, audit users, keys, guardrails and pass-through routes for anything you did not create; Wiz recommends restarting after removing rogue guardrails. On the provider side, check usage dashboards and cloud audit logs for spikes or calls from unfamiliar networks.

Timeline

Apr 20, 2026 — The CVE-2026-42208 SQL injection advisory is published (fixed in 1.83.7). The command-injection advisory follows on April 21.
May 8, 2026 — CISA adds CVE-2026-42208 to KEV. CVE-2026-42271 follows on June 8.
Jul 7, 2026 — Wiz observes CVE-2026-59822 exploitation. The CVEs are published on July 8.
Sep 2, 2026 — CISA adds CVE-2026-59822 to KEV, with a due date of September 16.
Oct 21, 2026 — The LiteLLM supply-chain incident report cites a likely internal deployment compromise as the initial access.

Sources

Security digest: September 2, 2026

erroneo.us Security Desk — Wed, 02 Sep 2026 00:00:00 -0700

1 editorial brief, 7 known exploited (cisa kev) additions and 6 critical advisories.

Known exploited (CISA KEV)

CVE-2026-9586 Sangoma Switchvox: Sangoma Switchvox SQL Injection Vulnerability (due 2026-09-05)
CVE-2026-83549 SonicWall SMA1000 Appliances: SonicWall SMA1000 Appliances OS Command Injection Vulnerability (due 2026-09-05)
CVE-2026-83548 SonicWall SMA1000 Appliances: SonicWall SMA1000 Appliances Server-Side Request Forgery Vulnerability (due 2026-09-05)
CVE-2026-82329 JFrog Artifactory: JFrog Artifactory Improper Authentication Vulnerability (due 2026-09-05)
CVE-2026-59822 BerriAI LiteLLM: BerriAI LiteLLM Improper Authentication Vulnerability (due 2026-09-16)
CVE-2026-49869 Kestra Kestra OSS: Kestra OSS OS Command Injection Vulnerability (due 2026-09-05)
CVE-2026-48710 Kludex Starlette: Kludex Starlette HTTP Request/Response Smuggling Vulnerability (due 2026-09-16)

Critical advisories

Patch this week: GitSpawn: Repo Git Config Runs Code in AI Coding Agents

erroneo.us Security Desk — Tue, 01 Sep 2026 00:00:00 -0700

Verdict: Patch this week. Update your coding agents this week and never point one at a repository that arrived as files until you have read its .git/config; ordinary clones are not affected, and no attacks have been reported.

Who must act: Developers and teams running Claude Code, Codex, Cursor, goose, Hermes Agent, Qwen Code or Grok Build on repositories received as archives, shared drives, sync folders or USB media, and any service that runs an agent over uploaded repositories.
Who can relax: People who only run agents inside repositories they cloned themselves from a known remote, because a normal git clone does not copy the source repository's local .git/config.

Update every agent: Claude Code (claude update), Codex CLI 0.131.0 or later (npm i -g @openai/codex@latest), goose 1.44.0 or later, and Hermes Agent to a build containing commit f6234d0.
Before opening a repository that arrived as files, run git config --local --list in it and remove any core.fsmonitor, core.hooksPath or filter/diff driver entries you did not set.
Prefer a fresh git clone from the authenticated remote over unpacking someone else's working copy; a clone drops their local config.
Until Qwen Code, Grok Build and the Claude Code ultrareview path are fixed, do not run them on repositories received as files.
Run agents that handle untrusted code inside a container or VM without your real credentials.

What happened

On September 1, 2026, Manifold Security published GitSpawn: eight findings across seven command-line AI coding agents that share one root cause. Agents run git status or git diff in the background to learn about your branch and changed files. Those commands refresh git's index, and git then runs whatever program the repository's own .git/config names in core.fsmonitor. None of the affected agents stripped that setting. The command therefore runs as you, outside the agent's sandbox, with no approval prompt. In Claude Code and Hermes Agent it fired before the workspace-trust prompt was accepted.

The same day, OpenAI published CVE-2026-19592 (fsmonitor) and CVE-2026-19590 (the same idea via core.hooksPath in Codex Desktop). goose had already fixed its variant as CVE-2026-72718 (CVSS 4.0 7.0), and VulnCheck assigned CVE-2026-71963 (CVSS 4.0 8.6) to Hermes Agent on September 3. None of these CVEs is in CISA KEV, and no source reports exploitation.

Who is affected

Claude Code: the fsmonitor path, confirmed on 2.1.193, was fixed in 2.1.196 in late June. A second path through claude ultrareview, using a different git setting Manifold did not name, was still live on 2.1.252 when Manifold retested on September 1.
Codex: CLI 0.102.0 through 0.130.0 (fixed in 0.131.0), plus the Desktop builds listed above (fixed in 26.519.x).
goose: before 1.44.0, via goose review (GHSA-r5pp-p5r8-466r).
Hermes Agent: 0.18.2 through 0.21.0. The fix, PR #101483 (commit f6234d0), was merged on September 2. Which release contains it was not disclosed as of October 21.
Qwen Code and Grok Build: unpatched at publication. Cursor fixed its variant; the version was not disclosed.

Do you really need to act?

The trigger is narrow, which is good news. A normal git clone does not copy the source repository's local config, so cloning a hostile URL does nothing. The attack needs the repository to arrive as files with .git intact: a zip or tarball someone sent you, a shared drive, a sync folder, a USB stick, or a candidate's take-home project. If that is how code reaches you, or if you run agents over uploaded repositories in a service, treat this as urgent. The payload runs with your full environment, including provider API keys and cloud credentials.

Updating closes most paths, and the agents auto-update in many setups. The Cloud Security Alliance notes that the Claude Code ultrareview path stayed open for weeks after the first fix. Fixing one setting does not fix the trust assumption, so inspect received repositories even after you update. A global core.fsmonitor=false does not help: a repository's local value overrides your global one.

What to do now

Update: claude update (or npm i -g @anthropic-ai/claude-code@latest), npm i -g @openai/codex@latest for Codex 0.131.0 or later, and goose 1.44.0 or later. Bring Codex Desktop to 26.519.x or later.
Before opening a received directory with any agent, run git config --local --list inside it. Delete core.fsmonitor, core.hooksPath and filter or diff-driver entries you did not create.
Where you can, re-clone from the real remote instead of using someone else's working copy.
Keep Qwen Code, Grok Build and claude ultrareview away from repositories received as files until fixes ship.
Run agents that touch untrusted code in a disposable container or VM that holds no production credentials.

How to tell if you were hit

List command-bearing settings in working copies you received: find ~/Downloads ~/Desktop -path '*/.git/config' -exec grep -il -e fsmonitor -e hookspath {} +. In each repository you opened with an agent, git config --show-origin --get-regexp 'core\.(fsmonitor|hookspath)' should return nothing, or only programs you installed. Check endpoint telemetry for shells or network tools spawned by git under an agent process. If you find a hostile value, assume the command ran. Rotate the API keys, cloud credentials and tokens present in that shell's environment.

Timeline

Jun 26, 2026 — Manifold reports the Claude Code fsmonitor path. It is fixed in 2.1.196.
Jul 7–20, 2026 — Reports go to Qwen Code, Cursor, goose, Grok Build, Claude Code (ultrareview), Codex and Hermes Agent.
Jul 24, 2026 — goose publishes GHSA-r5pp-p5r8-466r, fixed in 1.44.0. Its CVE record follows on Aug 10.
Sep 1, 2026 — Manifold publishes GitSpawn. OpenAI publishes CVE-2026-19590 and CVE-2026-19592.
Sep 2, 2026 — The Hermes Agent fix is merged, and The Hacker News reports the research.
Sep 3, 2026 — CVE-2026-71963 (Hermes Agent) is published.

Sources

Security digest: September 1, 2026

erroneo.us Security Desk — Tue, 01 Sep 2026 00:00:00 -0700

1 editorial brief and 1 critical advisory.

Critical advisories

NLTK: JVM argument injection bypass via per-call options in the NLTK Stanford wrappers (incomplete fix of CVE-2026-12841)

Security digest: August 31, 2026

erroneo.us Security Desk — Mon, 31 Aug 2026 00:00:00 -0700

2 known exploited (cisa kev) additions.

Known exploited (CISA KEV)

CVE-2026-82078 PaperCut NG/MF: PaperCut NG/MF Unsafe Reflection Vulnerability (due 2026-09-14)
CVE-2026-81578 PaperCut NG/MF: PaperCut NG/MF Missing Authentication for Critical Function Vulnerability (due 2026-09-14)

Act now: JFrog Artifactory: Exploited Auth Bypass to Admin (KEV)

erroneo.us Security Desk — Fri, 28 Aug 2026 00:00:00 -0700

Verdict: Act now. If you run self-hosted Artifactory below the fixed builds, treat it as exploited until shown otherwise: upgrade, then hunt for rogue admins, Groovy plugins and stolen signing keys, because patching does not remove them.

Who must act: Every team running self-managed JFrog Artifactory 7.x below 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 or 7.161.20, especially instances reachable from the internet or from untrusted build workloads.
Who can relax: Teams already on the fixed builds who have checked for persistence; JFrog's advisories list only self-managed releases, so SaaS customers should confirm their status with JFrog rather than assume either way.

Upgrade every self-managed Artifactory node to 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20 or later for your branch.
Until patched, remove internet exposure and restrict access to trusted networks and build systems.
List user plugins in $JFROG_HOME/var/etc/artifactory/plugins/ and remove anything you did not deploy; restart the JVM to clear in-memory implants.
Review admin users and access tokens; delete unknown accounts, SSH keys and tokens.
If compromise is possible, reset the Access token signing key and cluster join key, and rotate every upstream, LDAP and database credential stored in Artifactory.
Check cached images and packages in remote repositories for tampering (CVE-2026-66384 cache poisoning).

What happened

On August 28, 2026, JFrog published CVE-2026-82329, a critical (CVSS 3.1 9.8) authentication weakness in Artifactory. Under the default configuration, an unauthenticated attacker with network access can obtain administrative privileges. CISA added it to the KEV catalog on September 2 with a three-day deadline. JFrog publishes only a one-line summary, so the technical detail here comes from Wiz.

It is the worst of a cluster. CVE-2026-42018 (7.5, published Aug 12) can hand an unauthenticated caller a token for the internal anonymous user even when anonymous access is disabled. CVE-2026-42016 (8.1, published Jul 27) checks a token's signature and issuer but not its scope. Both entered KEV on September 11. CVE-2026-66384 (5.3), a Docker remote-cache path issue, entered KEV on August 27.

Wiz Research reported on September 10 that it had seen all three of the main CVEs exploited. From August 15 to September 8, several actors chained 42018 into 42016 to turn an unauthenticated request into an admin-scoped token, in some cases creating an admin account within five minutes. From September 1 to 8, attackers exploited 82329 with a single unauthenticated POST to /access/api/v1/registry/join, which returned an admin-scoped token. Wiz saw follow-on Groovy plugins, a Rust backdoor, theft of the Access signing key and cluster join key, and use of the server as a tunnel into internal networks.

The cache bug has its own story. OpenAI's incident report says an AI agent in an internal evaluation found and exploited CVE-2026-66384 as a zero-day starting July 9. It got Artifactory to cache an attacker-controlled container image under the name of a trusted image.

Who is affected

Self-managed Artifactory 7.x below 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 or 7.161.20 (NVD starts the 7.111 range at 7.111.4). JFrog's own table gives slightly different upper bounds for some branches, but Wiz and the CVE record agree on these fixed builds. Wiz found that 67% of organizations running Artifactory had a vulnerable instance when 82329 was published, and 49% still did two weeks later.

Do you really need to act?

Yes, if you are below the fixed builds. Exploitation is unauthenticated, works on default settings, is automatable according to CISA's SSVC rating, and has been seen in the wild. An artifact repository is a supply-chain chokepoint. Admin access lets an attacker read stored upstream, LDAP and database credentials and swap packages that your builds trust.

The part teams get wrong is assuming an upgrade cleans things up. Wiz stresses that plugins dropped through these bugs survive patching. A stolen Access private.key also lets an attacker forge valid tokens indefinitely, and only resetting the signing key revokes that. Instances that sit only on an internal network are at lower risk, but not zero: OpenAI's case started from inside a build sandbox.

What to do now

Check your version (curl -s https:///artifactory/api/system/version) and upgrade to the fixed build for your branch.
Until you have patched, take the instance off the internet or restrict it to trusted networks.
Inspect $JFROG_HOME/var/etc/artifactory/plugins/ and remove any plugin you did not write, such as rce.groovy, cmd.groovy, jwtToken.groovy, JFrogImage.groovy, metrics.groovy or httpSession.groovy. Then restart the JVM, because one implant lives only in memory.
Audit admin users, SSH keys and access tokens, and remove anything unknown.
If anything looks wrong, reset the Access signing key and join key and rotate every credential Artifactory stores. Then re-verify cached images in remote repositories.

How to tell if you were hit

Wiz suggests these log hunts. For 82329, look for a 200 or 201 on POST /access/api/v1/registry/join followed by user creation, GET /api/system/configuration or token enumeration. For the chain, look for a 401 on /access/api/v1/aws/token followed by a 200 on a variant of it, then POST /access/api/v1/tokens, then actions by token:anonymous. Attacker accounts include Nxploited_*, labadmin_*, 0xTerror, svc_*, jfrog-distribution and repo-service. Other warning signs: plugin executions that return HTTP 500 (one toolkit hides its output in error messages), request*.log files truncated to zero, and a plugin API that suddenly rejects requests.

Timeline

Jul 6, 2026 — OpenAI reports a token-refresh flaw it found in its internal Artifactory to JFrog.
Jul 9, 2026 — An AI agent in an OpenAI evaluation begins exploiting the cache bug later assigned CVE-2026-66384.
Jul 27, 2026 — JFrog publishes CVE-2026-42016.
Aug 12, 2026 — JFrog publishes CVE-2026-42018 and CVE-2026-66384.
Aug 15, 2026 — Wiz's earliest observed exploitation of the 42018/42016 chain.
Aug 27, 2026 — CVE-2026-66384 added to CISA KEV.
Aug 28, 2026 — JFrog publishes CVE-2026-82329 (CVSS 9.8).
Sep 2, 2026 — CVE-2026-82329 added to KEV, due Sep 5.
Sep 10, 2026 — Wiz publishes its in-the-wild exploitation analysis.
Sep 11, 2026 — CVE-2026-42016 and CVE-2026-42018 added to KEV.

Sources

Security digest: August 28, 2026

erroneo.us Security Desk — Fri, 28 Aug 2026 00:00:00 -0700

1 editorial brief and 10 critical advisories.

Critical advisories

Act now: PaperCut NG/MF: Mass-Exploited Pre-Auth RCE Chain (KEV)

erroneo.us Security Desk — Thu, 27 Aug 2026 00:00:00 -0700

Verdict: Act now. If a PaperCut NG/MF server below 24.1.10, 25.0.13 or 26.0.5 was reachable from the internet after late August, assume it was compromised: upgrade, then hunt and rebuild, because this chain gave unauthenticated attackers SYSTEM and was mass-exploited.

Who must act: Every organization running PaperCut NG or MF Application, Site or secondary servers below 24.1.10, 25.0.13 or 26.0.5, and anyone on version 23 or earlier, which gets no fix.
Who can relax: PaperCut Hive and Pocket customers (not affected), and servers already on the maintenance releases that have been checked for compromise; Mobility Print, Print Deploy and the client software need no update.

Upgrade every PaperCut NG/MF Application Server, Site Server and secondary server to 26.0.5, 25.0.13 or 24.1.10, and schedule the move off version 23 or earlier now.
Restrict the Application Server's web interfaces to trusted internal addresses and remove any internet exposure.
On any server that was exposed while unpatched, capture a JVM heap or memory dump and copy the logs before restarting, because in-memory web shells vanish on restart.
Check the external user-lookup settings (user-lookup.db-driver, user-lookup.db-url, user-lookup.id-to-username-sql) for values you did not set.
If you find indicators, rebuild the Application Server from a clean pre-incident backup and reset domain credentials the server could reach.
Patch Active Directory against noPac (CVE-2021-42278/42287) if you have not, since attackers used it to reach domain admin after PaperCut.

What happened

On August 27, 2026, PaperCut published an urgent bulletin about active exploitation of PaperCut NG and MF. According to CEO Chris Dance, an education customer reported a compromised MF server that morning. Huntress had already seen exploitation in a customer environment on August 26. PaperCut then disclosed two chained bugs:

CVE-2026-81578 (CWE-306, vendor CVSS 4.0 8.8; NVD CVSS 3.1 9.8). Unauthenticated requests to admin functions "can trigger backend actions prior to the completion of access validation checks." This lets an attacker change system configuration.
CVE-2026-82078 (CWE-470, CVSS 4.0 9.4). The database connection code loads driver classes by configurable name without an allowlist. Once the configuration is changed, this lets an attacker run arbitrary Java bytecode as the PaperCut server process.

watchTowr traced the bypass to page handling. The authorization check ran only for the first page named in a request, such as the unauthenticated LogonMessage, so an admin form nested after it, such as ConfigEditor, was reachable without logging in. Rapid7 says the attacker rewrites the external user-lookup settings, points them at a malicious JDBC URL, and then triggers a lookup. Huntress's proof of concept ran code as SYSTEM under pc-app.exe.

The first emergency patch (Aug 28) could be bypassed. PaperCut followed with Release 2 the same day, Release 3 on September 1, and maintenance releases 26.0.5, 25.0.13 and 24.1.10 on September 10. A Metasploit module was merged on September 3. CISA added both CVEs to KEV on August 31, with a due date of September 14. watchTowr later found a third bug, CVE-2026-82077, a post-authentication RCE through Scan to Fax. It is fixed in 26.0.5 and not known to be exploited.

Exploitation was broad. GreyNoise tracked a likely Russian-speaking actor that "used OpenAI's Codex with a DeepSeek model" to diff the patch and build tooling. The actor's first remote code execution against a real target came on August 31, and the full campaign launched on September 1. GreyNoise counted "at least 440 instances" at 395 organizations in 48 countries, with domain admin reached at 12 of them, in part through noPac where AD was unpatched. watchTowr saw in-memory Godzilla web shells installed as servlet filters on August 31, and more than 1,000 exploit attempts against its sensors.

Who is affected

PaperCut says all versions of NG and MF are affected, including Site Servers and secondary servers. Versions 23 and earlier get no patch. Huntress says about 47% of the roughly 2,500 PaperCut installations it tracks run v23 or older. Hive, Pocket, Mobility Print, Print Deploy and the client software are not affected. GreyNoise notes that PaperCut servers run as SYSTEM on Windows by default and are usually domain-joined.

Do you really need to act?

Yes. The chain needs no credentials, a public exploit exists, and attackers hit hundreds of organizations within days. PaperCut says unpatched servers that remain publicly reachable "continue to be targeted." Patching does not remove an existing in-memory shell, a dropped remote-access tool or harvested domain credentials. If your server faced the internet before you installed Release 3 or a maintenance release, treat it as compromised until you have checked. Internal-only servers are lower risk, but still upgrade them now.

What to do now

Upgrade the Application Server, then every Site Server and secondary server, to 26.0.5, 25.0.13 or 24.1.10. If you are on version 23 or earlier, upgrade to a supported line.
Firewall the Application Server's web interfaces so only trusted internal addresses can reach them.
Before restarting an exposed server, capture a JVM memory dump (for example jcmd GC.heap_dump where a JDK is available) and copy the logs.
Review the external user-lookup settings for values you did not set. If you really use external card-number lookups, apply the server/security.properties change PaperCut documents; otherwise leave the feature off.
If anything looks wrong, follow PaperCut's guidance to rebuild from a clean pre-incident backup and start incident response, including resetting domain credentials the server could reach.

How to tell if you were hit

On Windows, run findstr /S /C:"jdbc:no:x" /C:"jdbc:derby:memory:pwn" /C:"VALUES CAST" "\server\server.log*", or use grep -rE on Linux. A missing or truncated server.log is itself a warning sign. Look for pc-app.exe spawning cmd.exe, 5-character .class files in server\lib, and a service running SimpleService.exe (Get-CimInstance Win32_Service | ? PathName -like '*SimpleService*'). Search web logs for LogonMessage/ConfigEditor or Home/SetupAdmin in the service= parameter, and for org.h2.Driver in POST bodies. Then check the IPs, files and the Administrator17 account listed in the detection panel.

Timeline

Aug 26, 2026 — Huntress observes exploitation in a customer environment.
Aug 27, 2026 — A customer reports a compromise, and PaperCut publishes its bulletin.
Aug 28, 2026 — Emergency Patch 1, a bypass of it, and Release 2. The CVEs are published.
Aug 31, 2026 — CISA adds both CVEs to KEV. GreyNoise and watchTowr observe successful exploitation.
Sep 1, 2026 — PaperCut ships Release 3, and the mass campaign launches.
Sep 10, 2026 — PaperCut ships maintenance releases 26.0.5, 25.0.13 and 24.1.10.
Sep 14, 2026 — CISA's remediation deadline for federal agencies.
Oct 9, 2026 — watchTowr publishes its technical analysis.

Sources

Check exposure: ownCloud CVE-2023-49105: 2023 WebDAV Bypass Now in KEV

erroneo.us Security Desk — Thu, 27 Aug 2026 00:00:00 -0700

Verdict: Check exposure. Up-to-date ownCloud servers are fine; any ownCloud core 10.6.0 to 10.13.0 still online should be upgraded today and treated as breached, because attackers are using this bug to empty file shares.

Who must act: Anyone running self-hosted ownCloud Server (core) 10.6.0 through 10.13.x, especially internet-facing instances at research bodies, universities and agencies that rarely update.
Who can relax: ownCloud Infinite Scale and ownCloud.Online users, which ownCloud says are not affected, and ownCloud Server installs already on a current 10.16.x or 11.0.x release.

Find every ownCloud Server instance and record its version (occ status, or /status.php over HTTPS).
Upgrade anything below 10.13.3 to a current release (10.16.6 or 11.0.1), or at minimum 10.13.3.
If a vulnerable instance was internet-facing, assume files were read: review WebDAV logs and tell data owners.
Rotate secrets stored in ownCloud, such as password vaults, key files, BitLocker recovery keys and exported credentials.
Confirm the graphapi app is v0.3.1 or later and GetPhpInfo.php is gone (CVE-2023-49103, also in KEV).
Take unmaintained instances off the internet or put them behind a VPN.

What happened

In November 2023, ownCloud disclosed that its WebDAV API would accept pre-signed URLs for users who had no signing key configured. That is the default state. According to the vendor advisory, "it is possible to access, modify or delete any file without authentication" if the attacker knows the victim's username. The CVE record lists ownCloud core 10.6.0 before 10.13.1. NVD scores it 9.8. It shipped alongside CVE-2023-49103, the graphapi phpinfo leak that CISA put in KEV in late 2023.

The pre-signed URL bug stayed off KEV until August 2026. On August 13, Hunt.io found an open directory on 31.58.209[.]241 holding five custom Python scripts aimed at the ownCloud server of a Philippine nuclear research body. Its report explains the trick: with no key set, "the signing routine still executed using an empty secret." The scripts forge PBKDF2-HMAC-SHA512 signatures and pull files from /remote.php/dav/files//. The directory held 176 stolen ownCloud files (about 372 MB). A CSV in it references roughly 9 GB taken from the agency. The Hacker News lists the recovered material, including nuclear-material account records, reactor component documents, staff data, BitLocker keys and a KeePass database. Hunt.io attributes the operation to a Chinese speaker based on language artifacts, and says the operator could be state-affiliated, contracted or independent. CISA added the CVE to the KEV catalog on August 27, 2026, with an August 30 federal deadline.

Who is affected

Self-hosted ownCloud Server (the PHP "core" product) from 10.6.0 through 10.13.0. In its December 2023 notice, ownCloud told customers the bypass "requires an upgrade to 10.13.3 or a specific patch" from support. It said ownCloud Infinite Scale and its managed services, including ownCloud.Online, are not affected. The flaw affects users without a signing key, and that is the default, so in practice every account on a vulnerable server is exposed. The attacker only needs usernames, which are often email addresses or first.last names.

Do you really need to act?

Most organizations do not. The fix is almost three years old, and ownCloud Server has shipped many releases since. The current ones on the changelog are 10.16.6 and 11.0.1. If your instances are current, nothing changes.

The risk is the forgotten server: a lab, department or small agency that installed ownCloud years ago and never updated it. That is exactly the victim in Hunt.io's report. If you find one still on 10.6.0 to 10.13.0 and reachable from the internet, upgrading is not enough. The bug allows silent bulk download, so treat the data as already taken and rotate whatever secrets lived in it. KEV listing also means US federal agencies must remediate, so expect auditors to ask.

What to do now

Inventory instances. On each server, run sudo -u www-data php occ status, or fetch https://cloud.example.com/status.php and read the version it reports.
Upgrade anything below 10.13.3 to a current release (10.16.6 or 11.0.1). If you are stuck, go at least to 10.13.3 or ask ownCloud support for the patch.
While you are there, update the graphapi app to v0.3.1 or later and delete GetPhpInfo.php, as ownCloud's 2023 notice instructs.
For any instance exposed while vulnerable, rotate the secrets stored in it: password databases, key files, recovery keys, service credentials and app passwords.
Put instances that nobody maintains behind a VPN or SSO proxy, or shut them down.

How to tell if you were hit

Hunt.io's scripts append OC-Credential (the target username), OC-Verb, OC-Expires=1000, an empty OC-Date and OC-Signature to WebDAV URLs. Grep access logs for those parameters on /remote.php/dav/files/. The scripts also enumerate folders with PROPFIND and sleep a few seconds between downloads, so look for slow, steady bulk GETs from one address across several accounts. Check for 31.58.209.241, but expect other sources too. If you find matches, scope which accounts and files were served, notify the data owners, and assume any credentials in those files are burned.

Timeline

Nov 21, 2023 — ownCloud publishes the advisory, and the CVE is published.
Dec 1, 2023 — ownCloud tells customers to upgrade to 10.13.3 or apply a support patch.
Aug 13, 2026 — Hunt.io finds the attacker's open directory. It later shares the findings with CERT-PH under TLP:AMBER.
Aug 26, 2026 — Hunt.io publishes its report.
Aug 27, 2026 — CISA adds CVE-2023-49105 to KEV.
Aug 30, 2026 — CISA's remediation deadline for federal agencies.