DEV Community: HOL (Hashgraph Online)

Cisco SD-WAN Manager admin API bypass hits CISA KEV

Michael Kantor — Wed, 30 Sep 2026 17:18:42 +0000

Originally published at HOL

CISA added CVE-2026-76504 to the Known Exploited Vulnerabilities catalog today (2026-09-30). Cisco Catalyst SD-WAN Manager has a hex/URI-encoding bug: an unauthenticated remote attacker who can reach the Manager can bypass the API session auth rule and land on the admin API. Cisco published advisory cisco-sa-sdwan-webauth-xr8beuuU this morning, rates it CVSS 3.1 base 9.8, and says PSIRT became aware of active exploitation in September 2026. There are no workarounds. Federal KEV due date is 2026-10-03. Forensic triage is Yes under BOD 26-04. Known ransomware campaign use is Unknown.

This is the KEV follow-up to our same-day BREAKING write-up: Cisco SD-WAN Manager admin API open without a login (CVE-2026-76504). That page still has the full operator detail. This page adds the CISA KEV clock (catalogVersion 2026.09.30, dateAdded 2026-09-30) and the federal triage due date. The HOL Guard evidence pack for CVE-2026-76504 is the linked source record.

Who is not in scope

Cisco Catalyst SD-WAN Cloud Hosted (Cisco Managed): Cisco already shipped fixed Release 20.15.605. No customer action. Confirm status from Help in the service GUI.
On-prem / customer-managed Managers already on a fixed build: 20.9.10.1+, 20.12.8.2+, 20.15.6.1+, 20.18.4.1+, 26.1.2.1+, or 26.2.1+ on the matching train. Releases earlier than 20.9 must migrate to a fixed release.
Products Cisco did not list: only Cisco Catalyst SD-WAN Manager is named in this advisory. Do not treat a random IOS-XE or Meraki advisory as coverage for 76504.

If your Manager is internet-reachable on the management plane, treat it as exposed until the build is fixed. Cisco says the product is affected regardless of system configuration. Config flags do not carve you out of KEV.

What breaks

SD-WAN Manager's API session auth mishandles URI encoding (CWE-177). A crafted HTTP request can skip the rule that is supposed to keep unauthenticated callers off a specific API endpoint (Cisco ties this to j_security_check). A successful exploit gives admin-user API access. Cisco Bug ID: CSCww79570. CISA's KEV short description matches: hex encoding vulnerability, unauthenticated remote attacker can access the affected system with admin privileges due to improper handling of URI encoding in an HTTP request.

Cisco's Indicators of Compromise section shows URI-encoding a character inside that path (example: %6a for j). Encoding any one character in the request can be enough. Treat that as an example, not the only payload shape. Same-day KEV means the federal clock and BOD 26-04 forensic triage apply even if you already started patching from this morning's advisory.

What this is not

This is not a local misconfiguration bug, and it is not limited to Managers that enabled some optional feature. It is also not an RCE advisory by name: the documented impact is unauthenticated admin API access. Network exposure reduction is a temporary mitigation for on-prem only, not a fix. KEV does not invent a new bug; it marks this CVE as known-exploited with a due date.

How to check

Confirm the Manager software version from the GUI Help panel or your inventory against the fixed table below. Then audit the logs Cisco names for URI-encoded j_security_check hits and viptela-reserved- system account activity from unknown IPs.

# service-proxy access log (example path from the advisory)
# /var/log/nms/containers/service-proxy/serviceproxy-access.log
# Look for URI-encoded j_security_check from unknown sources, e.g.:
# POST /%6a_security_check HTTP/1.1  200

grep -E 'j_security_check|%6[aA]_security_check|%[0-9A-Fa-f]{2}_security_check'   /var/log/nms/containers/service-proxy/serviceproxy-access.log
vManage server log
/var/log/nms/vmanage-server.log
Look for j_security_check stored for viptela-reserved- users

Cisco notes these IOC patterns can also appear in normal operations, so compare against your baseline. For suspected compromise, collect request admin-tech from the Manager and open a Severity 3 TAC case with CVE-2026-76504 in the title. Federal agencies under BOD 26-04 also owe forensic triage by the KEV due date.

How to fix

Upgrade on-prem / customer-managed Cisco Catalyst SD-WAN Manager to the first fixed release on your train (or later on that train):

Earlier than 20.9: migrate to a fixed release
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

Use the Catalyst SD-WAN Control Component Compatibility Matrix and the Cisco Catalyst SD-WAN Upgrade Matrix before you cut over. There is no software workaround. For on-prem Managers that must stay online during the window, Cisco's temporary mitigation is to keep the management plane off untrusted networks: put Control Components behind a filtering device, allow only known trusted hosts, and follow the Cisco Catalyst SD-WAN Hardening Guide. That mitigation is already deployed for Cloud Hosted environments. Federal due date under this KEV row is 2026-10-03.

References

CISA Known Exploited Vulnerabilities catalog (CVE-2026-76504, dateAdded 2026-09-30, dueDate 2026-10-03, catalogVersion 2026.09.30, BOD 26-04, forensic triage Yes, ransomware Unknown)
Cisco Security Advisory: cisco-sa-sdwan-webauth-xr8beuuU (CVE-2026-76504)
HOL BREAKING write-up (same-day advisory)

BREAKING: Cisco SD-WAN Manager admin API open without a login (CVE-2026-76504)

Michael Kantor — Wed, 30 Sep 2026 13:50:32 +0000

Originally published at HOL

Cisco published advisory cisco-sa-sdwan-webauth-xr8beuuU today (2026-09-30) for CVE-2026-76504. An unauthenticated remote attacker who can reach Cisco Catalyst SD-WAN Manager can bypass the API session auth rule with a URI-encoded request and land on the API as the admin user. Cisco rates it CVSS 3.1 base 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The bug is CWE-177 (Improper Handling of URL Encoding). There are no workarounds. The advisory says the product is affected regardless of system configuration. Cisco PSIRT became aware of active exploitation in September 2026. Fixed trains: 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1, and 26.2.1. Cloud Hosted (Cisco Managed) is already on 20.15.605 with no customer action. This page is the operator write-up from the Cisco Security Advisory. The HOL Guard evidence pack for CVE-2026-76504 is the linked source record.

Who is not in scope

Cisco Catalyst SD-WAN Cloud Hosted (Cisco Managed): Cisco already shipped fixed Release 20.15.605. No user action is required. Check status or version from Help in the service GUI.
On-prem / customer-managed Managers already on a fixed build: 20.9.10.1+, 20.12.8.2+, 20.15.6.1+, 20.18.4.1+, 26.1.2.1+, or 26.2.1+ on the matching train. Releases earlier than 20.9 must migrate to a fixed release.
Products Cisco did not list: only Cisco Catalyst SD-WAN Manager is called out as vulnerable in this advisory.

If your Manager is internet-reachable on the management plane, treat it as exposed until the build is fixed. Config flags do not carve you out: Cisco says the product is affected regardless of system configuration.

What broke

SD-WAN Manager's API session auth management mishandles URI encoding. A crafted HTTP request can skip the rule that is supposed to keep unauthenticated callers off a specific API endpoint (the advisory ties this to j_security_check). A successful exploit gives the attacker admin-user API access. Cisco Bug ID: CSCww79570. The vulnerability was found while resolving a Cisco TAC support case.

Cisco's Indicators of Compromise section shows the pattern as URI-encoding a character inside that path (example: %6a for j). Encoding any one character in the request can be enough. Treat that as an example, not the only payload shape.

What this is not

This is not a local-only misconfiguration bug, and it is not limited to Managers that enabled some optional feature. Cisco states the product is affected regardless of configuration. It is also not an RCE advisory by name: the documented impact is unauthenticated admin API access. Cisco does state active exploitation in September 2026, and there are no workarounds that fix the bug itself. Network exposure reduction is a temporary mitigation for on-prem only.

How to check

# service-proxy access log (example path from the advisory)
# /var/log/nms/containers/service-proxy/serviceproxy-access.log
# Look for URI-encoded j_security_check from unknown sources, e.g.:
# POST /%6a_security_check HTTP/1.1  200

grep -E 'j_security_check|%6[aA]_security_check|%[0-9A-Fa-f]{2}_security_check'   /var/log/nms/containers/service-proxy/serviceproxy-access.log
vManage server log
/var/log/nms/vmanage-server.log
Look for j_security_check stored for viptela-reserved- users

How to fix

Upgrade on-prem / customer-managed Cisco Catalyst SD-WAN Manager to the first fixed release on your train (or later on that train):

Earlier than 20.9: migrate to a fixed release
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

References

Unsloth RCE: malicious Hugging Face model config.json injects code

Michael Kantor — Mon, 28 Sep 2026 15:29:07 +0000

Originally published at HOL

Unsloth RCE: malicious Hugging Face model config.json injects code

If you fine-tune or serve models with Unsloth and you load weights from Hugging Face (or any path that ships a config.json), a nested model_type string can turn into Python that Unsloth execs. Same-day record CVE-2026-93348 (CVSS 8.6 HIGH, CWE-94) covers Unsloth Zoo >=2025.9.9 and <2026.8.14, as pulled in by Unsloth >=2025.9.9 and <2026.8.20. The maintainer fix is already on PyPI: upgrade unsloth-zoo to 2026.8.14+ and unsloth to 2026.8.20+ (current wheels are newer). This is the operator write-up from the merged Unsloth Zoo patch and the VulnCheck advisory. The HOL Guard evidence pack is at /guard/security/cves/CVE-2026-93348-unsloth-zoo-code-injection-via-modeltype-in.

Who is not in scope

You can ignore this ticket if any of these hold:

You do not install or import unsloth / unsloth-zoo at all.
pip show unsloth-zoo reports 2026.8.14 or newer and pip show unsloth reports 2026.8.20 or newer (or you never pin the older train).
Your training / inference path never calls Unsloth's transformers compile / load helpers that read model_type from a downloaded config (plain transformers without Unsloth is a different stack).

Hugging Face Hub hosting alone is not the bug. The issue is what Unsloth does with a config field after you choose to load that model.

What broke

get_transformers_model_type() in unsloth_zoo/hf_utils.py walked nested model configs and collected model_type after a light normalize that rewrote -, /, and . to _. It did not enforce an [a-z0-9_] allowlist. A newline (or other injection) in a nested model_type inside a malicious model's config.json survived into the string that unsloth_compile_transformers() built for an import, then handed to exec(). The same string also shaped compiled cache filenames via create_new_function.

Merged Unsloth Zoo PR #1083 (follow-up #1108) and the Unsloth bump commit 92ee020 close that path. Credit for the report: Ariel Fogel (afogel) of Pillar Security, per the VulnCheck advisory.

One operator check

pip show unsloth-zoo unsloth | egrep '^(Name|Version):'

Treat any unsloth-zoo below 2026.8.14 or any unsloth below 2026.8.20 (on the affected train starting at 2025.9.9) as vulnerable until upgraded. If those packages are absent, you are out of scope for this CVE.

What this is not

This is not an unauthenticated internet worm and not a Hub-wide remote exploit against every Hugging Face user. CVSS 4.0 marks UI:P: someone (or a pipeline) has to load a malicious model so Unsloth's compile path runs as that user. Impact is still full code execution as the loading account once that happens, which is why the score sits at 8.6 HIGH.

How to fix

pip install -U "unsloth-zoo>=2026.8.14" "unsloth>=2026.8.20"

Or bump the same floors in your lockfile / image and redeploy. Re-run the pip show check above. Prefer pinned known-good model revisions from authors you trust; treat unknown config.json trees like untrusted code when they feed a compile path that used to exec interpolated imports.

What the patch actually changed (so you can sanity-check a backported fork):

Allowlist model_type with [a-z0-9_]+ immediately after the existing normalize in hf_utils.py (single choke point for Unsloth loaders).
Replace exec(f"import {model_location}") with importlib.import_module in the compiler path (keeping a deliberate import transformers for downstream eval call sites that still expect that binding).
Stop string-exec assignment in empty_model.set_additional_modules in favor of a dotted path walk.

PR #1083 reports the allowlist accepts every legitimate model_type shipped in the tested transformers matrices and rejects newline / quote / path-injection style payloads.

References

BREAKING: Unauthenticated NetScaler RCE hits every appliance (CVE-2026-88771)

Michael Kantor — Sun, 27 Sep 2026 16:45:55 +0000

Originally published at HOL

BREAKING: Unauthenticated NetScaler RCE hits every appliance (CVE-2026-88771)

Citrix published security bulletin CTX697096 on 2026-09-27 for eight NetScaler ADC / NetScaler Gateway flaws. The lead issue is CVE-2026-88771: unauthenticated remote code execution from improper input validation on every customer-managed NetScaler ADC and Gateway deployment, including default configuration. No extra feature has to be turned on. Citrix rates it CVSS v4.0 9.5 and states that exploits of CVE-2026-88771 and CVE-2026-88772 on unmitigated deployments have been observed. Fixed builds are 14.1-73.37, 13.1-64.23, 14.1-73.37 FIPS, and 13.1.37.279 FIPS/NDcPP. This is the operator write-up from CTX697096 and the CVE AWG records. The HOL Guard evidence pack for the lead CVE is at /guard/security/cves/CVE-2026-88771.

Who is not in scope

Skip the pager only if one of these is true:

Cloud Software Group already runs the appliance for you. CTX697096 applies to customer-managed NetScaler ADC and NetScaler Gateway only. Citrix-managed cloud services and Citrix-managed Adaptive Authentication are upgraded by CSG.
Every customer-managed ADC/Gateway instance you own is already on 14.1-73.37+, 13.1-64.23+, 14.1-73.37 FIPS+, or 13.1.37.279 FIPS/NDcPP+.

Do not confuse that cloud carve-out with Secure Private Access Hybrid. Citrix says Secure Private Access Hybrid deployments that use NetScaler instances are affected; you still upgrade those appliances to the builds above.

Sibling preconditions differ. CVE-2026-88772 needs DTLS enabled (on by default for VPN vServers unless you set -dtls OFF). CVE-2026-88775 needs Gateway or AAA. CVE-2026-88776 needs an Oracle LB vServer. CVE-2026-88771 does not: every default ADC/Gateway is in.

What broke

CTX697096 clusters eight CVEs on the same upgrade train. Treat them as one patch event.

CVE-2026-88771 (CVSS 9.5): unauthenticated RCE via improper input validation. All NetScaler ADC and Gateway deployments. Default configuration. No additional feature required.
CVE-2026-88772 (CVSS 9.5): memory overflow to RCE or DoS when DTLS is enabled. DTLS is enabled by default on VPN vServers.
CVE-2026-88773 (CVSS 9.3): HTTP request smuggling when HTTP is configured.
CVE-2026-88774 (CVSS 7.0): feature-policy bypass via HTTP URL-based policy expressions.
CVE-2026-88775 (CVSS 8.8): memory overflow / DoS on Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or AAA virtual servers.
CVE-2026-88776 (CVSS 8.8): memory overflow / DoS on Oracle-type LB virtual servers.
CVE-2026-88777 (CVSS 8.8): memory overflow / DoS on LB/CS or CGNAT-LSN/NAT64 with certain non-HTTP L7 features (FTP, RTSP, DNS64, NAT64, and related patterns in the bulletin).
CVE-2026-88778 (CVSS 8.8): TCP Initial Sequence Number prediction when TCP is configured and Enhanced ISN Generation is disabled.

Affected supported trains before the fixed builds: NetScaler ADC/Gateway 14.1 before 14.1-73.37, 13.1 before 13.1-64.23, ADC FIPS before 14.1-73.37 FIPS, and ADC FIPS/NDcPP before 13.1.37.279. Credit in the bulletin: Michael Tucker, Chew Keong Tan, and Alex Bernier (JPMorgan Chase XOR Team), and Maxim Suhanov.

What this is not

This is not a Gateway-only or AAA-only story. CVE-2026-88771 needs no special feature and hits every customer-managed NetScaler ADC and Gateway on the affected builds, including default config. It is also not limited to appliances you personally racked: Secure Private Access Hybrid NetScaler instances are in scope. Citrix-managed cloud and Adaptive Auth are the carve-out, not Hybrid SPA. CISA KEV caught up on 2026-09-27 for CVE-2026-88771 and CVE-2026-88772 (due 2026-09-30, forensic triage Yes). Citrix already stated exploits of both were observed on unmitigated deployments; treat the KEV rows plus CTX697096 as the operational clock.

How to check

Confirm the build the appliance is actually running:

show ns version

Anything on 14.1 below 14.1-73.37, on 13.1 below 13.1-64.23, on 14.1-FIPS below 14.1-73.37 FIPS, or on 13.1-FIPS/NDcPP below 13.1.37.279 is still in the RCE window for CVE-2026-88771.

For CVE-2026-88772 (DTLS), inspect VPN and DTLS virtual servers. Patterns from CTX697096:

# DTLS on by default (vulnerable precondition for 88772)
add vpn vserver vpn1 SSL 10.0.0.0 443 -Listenpolicy NONE

DTLS explicitly off (88772 precondition not met)
add vpn vserver vpn1 SSL 10.0.0.0 443 -dtls OFF -Listenpolicy NONE
explicit DTLS vServers (precondition met)

For CVE-2026-88778, confirm Enhanced ISN Generation:

show ns tcpparam | grep "Enhanced ISN Generation"

If that returns Enhanced ISN Generation: DISABLED and you have TCP-family virtual servers, apply the Enhanced ISN change from the NetScaler TCP configuration docs in addition to the build upgrade. The bulletin points at Enhanced ISN Generation.

How to fix

Upgrade customer-managed NetScaler ADC and NetScaler Gateway to one of these builds (or later on the same train):

NetScaler ADC / Gateway 14.1-73.37+
NetScaler ADC / Gateway 13.1-64.23+ (13.1 train)
NetScaler ADC FIPS 14.1-73.37 FIPS+
NetScaler ADC FIPS / NDcPP 13.1.37.279+

Pull the builds from Citrix support, stage in a maintenance window that matches your HA / GSLB cutover, then re-check with show ns version. For CVE-2026-88778, also enable Enhanced ISN Generation per the TCP configuration doc above. There is no feature-flag substitute for the CVE-2026-88771 fix: every default deployment is in scope until the build is current.

If you run Secure Private Access Hybrid on NetScaler instances, upgrade those instances to the same builds. Do not assume the Citrix-managed cloud carve-out covers them.

CISA KEV (added 2026-09-27)

CISA added CVE-2026-88771 and CVE-2026-88772 (both already covered in this NetScaler cluster write-up) to the Known Exploited Vulnerabilities catalog on 2026-09-27 (catalog version 2026.09.27). Federal and BOD 26-04 covered operators have until 2026-09-30. Both KEV rows require forensic triage (Yes). Ransomware use is listed as Unknown. Citrix already stated exploits of both CVEs were observed on unmitigated deployments; the KEV listing is the federal must-patch clock on the same upgrade train, not a new technical finding. Siblings CVE-2026-88773 through CVE-2026-88778 are not in the 2026-09-27 KEV batch.

References

WordPress page template include hits CISA KEV

Michael Kantor — Fri, 25 Sep 2026 20:22:34 +0000

Originally published at HOL

CISA added CVE-2026-87902 to the Known Exploited Vulnerabilities catalog today (2026-09-25). WordPress Core has an unauthenticated path traversal in page-template resolution: an attacker can make get_page_template() include a chosen readable local .php file outside the active theme directories. When the theme and PHP environment preconditions line up, that local file inclusion becomes remote code execution. GHSA-7hp8-65ch-5whp rates it critical (CVSS 4.0 9.2). Federal KEV due date is 2026-09-28. Forensic triage is Yes under BOD 26-04. Known ransomware campaign use is Unknown.

WordPress shipped the fix in 7.1.2 on 2026-09-22 and backported it through every supported branch back to 4.7. Patchstack reports probing hours after the patch, then active attempts that include pearcmd.php and write PHP to disk. This page is the operator write-up from the GHSA, the WordPress 7.1.2 release, CISA KEV, and Patchstack. The HOL Guard evidence pack for CVE-2026-87902 is the linked source record.

What breaks

Unauthenticated requests can abuse page-template resolution so WordPress includes a local .php the attacker picks, as long as that file is readable by the web server. The GHSA names two preconditions that turn LFI into conditional RCE:

Theme layout: the active child or parent theme has a top-level directory whose name starts with page- (for example page-templates). That hits legacy Twenty Twelve and Twenty Fourteen, plus popular third-party themes such as Neve, Hestia, and Sydney.
Readable target: a chosen local .php exists on disk. The well-known PEAR pearcmd.php path is the practical RCE transition when register_argc_argv is On. The official php Docker image is affected, and default cPanel with PHP prior to 8.5 is affected.

Affected trains run from WordPress 4.7.0 through 7.1.1. Fixed builds: 7.1.2, 7.0.6, 6.9.9, 6.8.10, and matching backports on every branch down to 4.7.37.

Who is not in scope

WordPress.com and hosts already on fixed builds for your branch (7.1.2 or the backport listed for your major).
Themes without a top-level page-* directory for the LFI-to-RCE path described in the GHSA. Upgrade anyway; the core sink is still patched for a reason.
Installs where no readable attacker-chosen .php exists (and PEAR / register_argc_argv is not available). That lowers immediate RCE odds; it does not cancel the KEV clock or the probing.
The earlier WordPress comment XSS story (CVE-2026-93485 / 7.1.1). Different bug, different fix train. Do not treat a 7.1.1 bump as coverage for 87902.

One operator check

Print the WordPress core version and compare it to the patched build for your branch:

# WP-CLI
wp core version
# or Dashboard → Updates, look for 7.1.2 (or your branch patch: 7.0.6, 6.9.9, 6.8.10, … back to 4.7.37)

Anything below the fixed build on that train is still open for this KEV row. If you run Docker php or cPanel PHP < 8.5 with PEAR present, treat the upgrade as urgent even when you think the theme is “safe.”

How to fix

Upgrade WordPress Core to 7.1.2, or to the security backport on your current major:

wp core update --version=7.1.2
# or update through Dashboard → Updates / your host’s managed WordPress channel

Branch matrix from GHSA-7hp8-65ch-5whp (vulnerable → fixed): 7.1.0–7.1.1 → 7.1.2; 7.0.0–7.0.5 → 7.0.6; 6.9.0–6.9.8 → 6.9.9; 6.8.0–6.8.9 → 6.8.10; continuing with matching patches on every branch back through 4.7.37. Prefer the path you already use (WP-CLI, dashboard, host panel). After the update, re-run wp core version. Federal agencies under BOD 26-04 also owe forensic triage; KEV due date is 2026-09-28.

What this is not

This is not unauthenticated RCE on every default WordPress install with zero preconditions. It is unauthenticated local file inclusion with conditional RCE when the theme has a page-* top-level directory and a readable target such as pearcmd.php is available. Still: CISA KEV today, Patchstack seeing pearcmd write-to-disk attempts, and a three-day federal due date.

References

GHSA-7hp8-65ch-5whp (WordPress Core)
WordPress 7.1.2 release
CISA Known Exploited Vulnerabilities catalog (CVE-2026-87902, dateAdded 2026-09-25, dueDate 2026-09-28, BOD 26-04)
Patchstack: probing hours after the patch / pearcmd write attempts
NVD CVE-2026-87902

SharePoint code injection hits CISA KEV

Michael Kantor — Fri, 25 Sep 2026 15:45:29 +0000

Originally published at HOL

CISA added CVE-2026-65660 to the Known Exploited Vulnerabilities catalog today (2026-09-25). Microsoft published the SharePoint Server Remote Code Execution row in the August 2026 security update (2026-08-11). Impact is Remote Code Execution via code injection (CWE-94). Severity is Important, CVSS 3.1 base 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Federal KEV due date is 2026-09-28. Forensic triage is marked Yes under BOD 26-04. Known ransomware campaign use is Unknown. MSRC still lists exploited: No on the advisory; CISA's KEV listing is the later exploitation signal. Do not treat MSRC's August wording as a clean bill of health after today.

This is the operator write-up from MSRC CVE-2026-65660, the August 2026 SharePoint KBs, CISA KEV catalogVersion 2026.09.25, and NVD. The HOL Guard evidence pack for this CVE, when it lands, is the linked source record; this page is the fix-first summary.

What breaks

MSRC rates this Important Remote Code Execution. An authenticated attacker with low-level access can send a specially crafted request and execute code on the SharePoint server. User interaction is not required. On-prem farms that still sit below the August 2026 fixed builds are the pager case, especially internet-facing SharePoint hosts where low-priv accounts are common.

Affected product lines and fixed builds from MSRC affectedProduct (release 2026-Aug):

SharePoint Server Subscription Edition: KB5002893 → build 16.0.19725.20522
SharePoint Server 2019: KB5002894 → build 16.0.10417.20198
SharePoint Enterprise Server 2016 (same KB also covers SharePoint Server 2016): KB5002905 → build 16.0.5565.1001

Reboot guidance on those rows is Maybe. If multiple updates apply for the software on the box, MSRC FAQ says install all of them; order does not matter.

Who is not in scope

SharePoint Online / Microsoft 365 cloud SharePoint. MSRC lists only the three on-prem server SKUs above. This KEV row is not a SharePoint Online patch ticket.
Farms already on or above the August 2026 fixed builds for your SKU (SE 16.0.19725.20522, 2019 16.0.10417.20198, 2016 16.0.5565.1001).
Unauthenticated internet worms as the PR:L model. The CVSS privileges-required is Low, not None. You still need an authorized (low-priv) attacker who can reach the farm.
Other Microsoft products outside those SharePoint Server trains named on this CVE. Patch them on their own advisories; do not treat 65660 as coverage for unrelated MSRC rows.

One operator check

On a SharePoint server, print the installed product build, then compare it to the fixed build for your SKU:

# SharePoint Management Shell / elevated PowerShell
(Get-SPFarm).BuildVersion.ToString()
# or, from the binaries folder for your train:
(Get-Item "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.dll").VersionInfo.FileVersion

You want at least 16.0.19725.20522 (Subscription Edition), 16.0.10417.20198 (2019), or 16.0.5565.1001 (2016 / Enterprise 2016). Anything lower on that train is still open for this KEV row.

How to fix

Install the August 2026 security update for your SharePoint Server SKU, then confirm the build:

Subscription Edition: KB5002893 → build 16.0.19725.20522
SharePoint Server 2019: KB5002894 → build 16.0.10417.20198
SharePoint Server 2016 / Enterprise Server 2016: KB5002905 → build 16.0.5565.1001

Prefer the path your farm already uses (WSUS / ConfigMgr / manual KB). After the update, re-run the build check above. Federal agencies under BOD 26-04 also owe forensic triage before or with the patch window; the KEV due date is 2026-09-28.

What this is not

This is not unauthenticated remote code execution. Privileges required are Low (an authorized attacker), not None. It is also not a first-day disclosure story: the MSRC update shipped 2026-08-11. Treat it as authenticated code injection RCE that CISA now says is known-exploited, on widely deployed on-prem SharePoint.

References

MSRC CVE-2026-65660
KB5002893 (Subscription Edition)
KB5002894 (SharePoint Server 2019)
KB5002905 (SharePoint Server 2016)
CISA Known Exploited Vulnerabilities catalog (CVE-2026-65660, dateAdded 2026-09-25, dueDate 2026-09-28, BOD 26-04)
NVD CVE-2026-65660

Magento incorrect authorization hits CISA KEV

Michael Kantor — Fri, 25 Sep 2026 02:30:38 +0000

Originally published at HOL

CISA added CVE-2026-71362 to the Known Exploited Vulnerabilities catalog today (2026-09-24). Adobe published APSB26-92 on 2026-08-11 for Adobe Commerce and Magento Open Source. The Critical row is Incorrect Authorization (CWE-863): privilege escalation with no login and no user click, CVSS 3.1 base 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). Federal KEV due date is 2026-09-27. Forensic triage is marked Yes under BOD 26-04. Adobe's August bulletin said it was not aware of exploits in the wild for the issues in that update; CISA's KEV listing is the later exploitation signal. Do not treat Adobe's August wording as a clean bill of health after today.

This is the operator write-up from APSB26-92, Adobe's Experience League KB for that bulletin, CISA KEV catalogVersion 2026.09.24, and NVD. The HOL Guard evidence pack for this CVE, when it lands, is the linked source record; this page is the fix-first summary. Sibling CVEs in the same August bulletin (XSS and other authz rows) share the upgrade train; this article tracks the KEV row only.

What breaks

Adobe rates CVE-2026-71362 Critical. Impact is privilege escalation: an attacker can gain elevated access to sensitive resources without authentication and without user interaction. Reporter credit on the bulletin: 0x0.eth (0x0doteth). Magento storefronts and Adobe Commerce backends that still sit on July 2026 security trains (or earlier) are the pager case, especially internet-facing commerce hosts.

Affected product lines from APSB26-92:

Adobe Commerce: 2.4.9-2026-jul and earlier, 2.4.8-2026-jul and earlier, 2.4.7-2026-jul and earlier, 2.4.6-2026-jul and earlier, 2.4.5-2026-jul and earlier, 2.4.4-2026-jul and earlier
Adobe Commerce B2B: 1.5.3-2026-jul and earlier, 1.5.2-2026-jul and earlier, 1.4.2-2026-jul and earlier, 1.3.4-2026-jul and earlier, 1.3.3-2026-jul and earlier
Magento Open Source: 2.4.9-2026-jul and earlier, 2.4.8-2026-jul and earlier, 2.4.7-2026-jul and earlier, 2.4.6-2026-jul and earlier

Fixed trains named in the bulletin are the matching August 2026 builds (*-2026-aug), including Adobe Commerce through 2.4.4-2026-aug, Magento Open Source through 2.4.6-2026-aug, and matching B2B *-2026-aug builds. Adobe's KB for APSB26-92 also ships Isolated security patch ZIPs for merchants who need a lighter path than a full Composer cycle; Cloud merchants may already receive the same fixes via Magento Cloud Patches. Confirm against the live bulletin and KB for your edition before you close the ticket.

Who is not in scope

Hosts already on the August 2026 security trains listed in APSB26-92 (*-2026-aug for your Commerce / Magento / B2B line), or that already show CVE-2026-71362 as protected in Adobe's Commerce Version Tool after the August Isolated patch.
Magento Open Source 2.4.5 / 2.4.4 lines for this specific bulletin row. APSB26-92 lists those trains under Adobe Commerce only, not under Magento Open Source.
Other Adobe products outside Commerce / Magento Open Source / Commerce B2B named in APSB26-92. This KEV row is not a free pass to ignore unrelated Adobe bulletins, but it is not their vulnerability either.
Prior Magento stories already on this blog (StyleSmuggler template RCE CVE-2026-75650, APSB26-138 authz CVE-2026-77774). Different CVEs, different upgrade trains. Do not treat those posts as coverage for 71362.

One operator check

From the Commerce / Magento project root, print the installed product version, then ask Adobe's patch-status tool whether CVE-2026-71362 is protected (CVT ships with the July 2026 Isolated patch train per Adobe's KB):

php bin/magento --version
php vendor/bin/patch-status --version
php vendor/bin/patch-status

Read applied_patches, missing_patches, and the per-CVE vulnerability_status for CVE-2026-71362 (PROTECTED / VULNERABLE / UNKNOWN). If patch-status is missing, you are not on a train that already pulled CVT; apply the July Isolated patch first per Adobe's KB, then re-run. Cloud-only alternative from the same KB: Quality Patches Tool status for the August Isolated patch id that matches your line.

How to fix

Move every affected Commerce / Magento / B2B install onto the August 2026 security train for your line (examples from APSB26-92: 2.4.9-2026-aug … 2.4.4-2026-aug for Adobe Commerce; Magento Open Source through 2.4.6-2026-aug; matching B2B *-2026-aug). Prefer the path your ops already use:

Composer / full security update when Adobe publishes packages for your line, or you are already on a Composer-based monthly security workflow.
Isolated security patch ZIP from Adobe's APSB26-92 KB when your line is classified as Isolated-only for August 2026 (Adobe notes Composer packages were not published alongside several of those trains). Apply July's Isolated patches first; August builds on July and must be applied in order. Example zip names from the KB include 2-4-9-aug-2026.zip, 2-4-8-p5-aug-2026.zip, 2-4-7-p10-aug-2026.zip, 2-4-6-p15-aug-2026.zip, and composer-key-gated zips for older Commerce lines.
Adobe Commerce on Cloud: pull the latest Magento Cloud Patches / cloud-patches update that includes APSB26-92. Adobe warns that stacking the Isolated ZIP on top of an already-patched cloud-patches install can fail.

After the update, re-run php vendor/bin/patch-status and confirm CVE-2026-71362 is PROTECTED. Federal agencies under BOD 26-04 also owe forensic triage before or with the patch window; the KEV due date is 2026-09-27.

What this is not

This is not a remote code execution bug in the Adobe table for CVE-2026-71362, and it is not a first-day disclosure story: APSB26-92 shipped 2026-08-11. Availability impact is listed as None in the CVSS vector. Treat it as unauthenticated privilege escalation that CISA now says is known-exploited, on a widely deployed commerce stack.

References

Adobe APSB26-92
Adobe Experience League: Security update APSB26-92 (Isolated patches / CVT)
CISA Known Exploited Vulnerabilities catalog (CVE-2026-71362, dateAdded 2026-09-24, dueDate 2026-09-27, BOD 26-04)
NVD CVE-2026-71362
GitHub Advisory GHSA-f58v-hxr9-8947 (unreviewed mirror of the CVE record)

F5 BIG-IP APM OAuth RCE hits CISA KEV

Michael Kantor — Tue, 22 Sep 2026 19:58:31 +0000

Originally published at HOL

CISA added CVE-2026-94127 to the Known Exploited Vulnerabilities catalog today (2026-09-22). F5 published the same-day advisory for BIG-IP Access Policy Manager: when an APM access policy and an OAuth profile share a virtual server, crafted traffic can trigger a heap buffer overflow and remote code execution with no login. Appliance mode is in scope. This is a data-plane bug; the control plane is not the exposure. Federal KEV due date is 2026-09-25. Forensic triage is marked Yes. CISA's notes say apply F5's temporary iRule for triage, then install the vendor hotfix.

This is the operator write-up from the F5 CVE record (K000162605), CISA KEV catalogVersion 2026.09.22, and NVD's received listing. The HOL Guard evidence pack for this CVE, when it lands, is the linked source record; this page is the fix-first summary.

What breaks

F5 rates the issue Critical. CVSS 3.1 base score is 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). CVSS 4.0 base from the CNA is 9.3. Weakness: heap-based buffer overflow (CWE-122). The precondition is configuration, not "every BIG-IP on the internet": the virtual server must have both an APM access policy and an OAuth profile attached. Under that setup, specific malicious traffic to the virtual server can reach RCE without authentication.

Affected trains from the F5 CNA record:

21.1.0 until Hotfix-BIGIP-21.1.0.2.0.30.22-ENG
17.5.0 (through the 17.5.1 line in secondary reporting) until Hotfix-BIGIP-17.5.1.9.0.160.12-ENG
17.1.0 (through 17.1.3 in secondary reporting) until Hotfix-BIGIP-17.1.3.5.0.41.14-ENG

Software past End of Technical Support is not evaluated. Treat internet-facing APM+OAuth virtual servers as the pager case. BOD 26-04 triage applies because this is same-day KEV.

Who is not in scope

Virtual servers without both an APM access policy and an OAuth profile. The CNA text gates the bug on that pair. LTM-only VIPs, or APM without OAuth (or OAuth without APM) on the same virtual server, are outside this specific failure mode.
Control-plane management paths as the attack surface. F5 states this is a data-plane issue with no control-plane exposure. That does not mean the box is safe; it means the exploit rides traffic to the VIP, not the config UI by itself.
Other BIG-IP modules and NGINX products called out as unaffected in secondary advisory summaries that track K000162605. Confirm against the live F5 article for your licensed modules before you close the ticket.
Boxes already on the listed engineering hotfixes for your train. The fix is the ENG hotfix named above, not a marketing point release alone.

One operator check

On each BIG-IP that terminates APM, run:

tmsh show sys version
tmsh list ltm virtual one-line | grep -E 'profiles|access-policy|oauth'

Confirm the software build, then inventory every virtual server that shows both an access policy and an OAuth profile. Any VIP that has both is in the KEV blast radius until the matching ENG hotfix is installed (or until you remove one of those two bindings as a temporary reduction of exposure).

If you already use a config-management export, grep the UCS/SCF for oauth profiles attached beside APM access policies on the same virtual server object. That is the same check without interactive tmsh.

How to fix

Install the F5 engineering hotfix for your train, then re-check version:

21.1.0: Hotfix-BIGIP-21.1.0.2.0.30.22-ENG
17.5.x: Hotfix-BIGIP-17.5.1.9.0.160.12-ENG
17.1.x: Hotfix-BIGIP-17.1.3.5.0.41.14-ENG

Pull the package from MyF5 per K000162605, stage it in a change window, and verify tmsh show sys version shows the hotfix build after reboot. If you cannot patch immediately, contact F5 Support for the vendor-provided iRule mitigation CISA references for forensic triage, restrict or disable the exposed APM+OAuth virtual servers where business allows, and treat the box as potentially compromised before you trust a late patch. KEV due date: 2026-09-25.

What this is not

This is not a worm that hits every BIG-IP regardless of config. It is unauthenticated RCE, but only after APM access policy and OAuth share a virtual server. It is also not a control-plane auth bypass; the overflow is on the data plane VIP path.

References

F5 advisory K000162605: https://my.f5.com/manage/s/article/K000162605
CVE record: https://www.cve.org/CVERecord?id=CVE-2026-94127
NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-94127
CISA KEV catalog (catalogVersion 2026.09.22): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
HOL Guard evidence pack: https://hol.org/guard/security/cves/CVE-2026-94127

BREAKING: CVE-2026-94545 Next.js next/og ImageResponse RCE (GHSA-vcvr-r3jv-pc5j)

Michael Kantor — Tue, 22 Sep 2026 17:43:23 +0000

Originally published at HOL

BREAKING: CVE-2026-94545 Next.js next/og ImageResponse RCE (GHSA-vcvr-r3jv-pc5j)

Vercel published an out-of-band Next.js security update on 2026-09-22. The Critical path is remote code execution in the Node.js ImageResponse implementation from next/og (CVE-2026-94545 / GHSA-vcvr-r3jv-pc5j, CVSS 9.5). It comes from improper SVG escaping in upstream Satori (GHSA-wx4j-mvgx-mqwp), which Next.js pulls in for OG image generation. Patched Next.js is 16.3.6. Next.js 15.x is not affected by the RCE; 15.5.26 is hardening only. GitHub now lists CVE-2026-94545 on GHSA-vcvr-r3jv-pc5j (NVD and cve.org still empty at patch time). This is the operator write-up from the Next.js blog and the GitHub advisories.

Who is not in scope

Skip the pager if any of these hold:

You already run next@16.3.6 or newer on the 16.x train.
The app is on Next.js 15.x for the RCE itself. The September 22 cut still ships 15.5.26 as related hardening, but the vendor states 15.x is not affected by this remote code execution issue.
You use only the Edge ImageResponse implementation. Edge is not affected.
Your Node.js ImageResponse handlers never pass attacker-controlled values into SVG content, attributes, or styles during image generation.

If a public OG route takes a query param, header, or other request field and drops it into JSX/SVG that ImageResponse renders on Node, treat yourself as in scope until you patch.

What broke

Next.js Node.js ImageResponse RCE (CVE-2026-94545 / GHSA-vcvr-r3jv-pc5j). Affected next versions are >= 16.2.0 and < 16.3.6. The Node.js path from next/og is vulnerable when attacker-controlled values reach SVG content, attributes, or styles. The advisory example wires a searchParams value into an SVG <title> inside ImageResponse. Under those conditions, improper escaping in Satori-generated SVG can lead to remote code execution through other upstream dependencies. The Next.js fix upgrades those dependencies. Severity on the GHSA is Critical 9.5 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H). Credit: KarimPwnz.

Upstream Satori improper SVG escaping (GHSA-wx4j-mvgx-mqwp). Satori versions >= 0.0.27 and < 0.33.5 do not properly escape certain values before including them in generated SVG. Crafted values can be interpreted as SVG markup. Impact depends on how the SVG is consumed. Patched Satori is 0.33.5. Severity is Moderate 5.3. For Next.js apps, do not chase a standalone Satori bump as the product fix; install the patched Next.js release that vendors the upgrade.

Confirmed on the npm registry today: next@16.3.6 and next@15.5.26 both resolve. The Next.js September 22, 2026 security update blog is live (no longer Upcoming). No matching Vercel changelog entry was present at publish time; use the Next.js blog and the two GHSAs as primary records.

What this is not

This is not the August 2026 Image Optimization AVIF / libheif RCE (GHSA-2xp9-vwfh-vxw4). It is not CVE-2026-75604, the Windows path-traversal RCE that needed both routers without Cache Components. It is not automatic RCE on every next/og use: Edge ImageResponse is out, and Node handlers that never feed attacker-controlled values into SVG content, attributes, or styles are out. CVE ID CVE-2026-94545 is now on the GHSA page; NVD and the CVE.org record may still lag. We are not inventing the ID. We are not claiming CISA KEV listing or in-the-wild exploitation; that status is unknown from the primary sources.

How to check

Confirm the next package the running process actually loaded:

npx next --version
# or
npm ls next

On the 16.x train, anything >= 16.2.0 and below 16.3.6 is in the RCE window. Then inventory Node.js OG routes that take request input into SVG:

# look for Node ImageResponse from next/og (not Edge-only handlers)
rg -n "from ['\"]next/og['\"]|ImageResponse" app pages src --glob '*.{js,jsx,ts,tsx}'
# then check whether searchParams, headers, cookies, or body fields land in SVG props/children/styles

If that path exists and you are still below 16.3.6, patch before you argue about whether the values are "really" attacker-controlled.

How to fix

npm install next@16.3.6   # 16.x Active LTS (RCE fix)
npm install next@15.5.26  # 15.x Maintenance LTS (hardening only; 15.x not affected by the RCE)

If you cannot upgrade immediately, the GHSA workaround is: do not pass attacker-controlled values into SVG content, attributes, or styles rendered by the Node.js ImageResponse implementation from next/og. That is a temporary constraint, not a substitute for 16.3.6 on affected 16.x apps.

HOL Guard does not have a source record for GHSA-vcvr-r3jv-pc5j yet (the Guard CVE evidence pack 404s today). Use the Next.js September 22, 2026 security update and the GitHub advisories as the primary records until Guard ingests it.

References

Your Erlang TLS 1.3 client can trust a server with no certificate

Michael Kantor — Tue, 22 Sep 2026 13:05:32 +0000

Originally published at HOL

An Erlang/OTP TLS 1.3 client can finish ssl:connect against a peer that never sent a certificate. Erlang published CVE-2026-89422 today (CVSS 4.0 9.3 Critical, CWE-322). If the ServerHello carries a pre_shared_key extension the client never offered, the default client marks the handshake as resumed, skips certificate path validation, hostname checks, verify_fun, CRL, and OCSP, and still returns {ok, Socket}. The peer needs no cert, no private key, and no prior session. After that handshake the attacker holds the traffic keys, so it can read credentials, tokens, and request bodies and forge every response.

Ship the same OTP upgrade for the same-day siblings CVE-2026-68956 (SSH idle session-channel memory DoS, CVSS 4.0 7.1 High) and CVE-2026-65634 (ASN.1 OBJECT IDENTIFIER decode CPU DoS during TLS cert parsing, CVSS 4.0 8.2 High). Do not open a second article for that train. This is the operator write-up; the HOL Guard evidence packs for CVE-2026-89422, CVE-2026-68956, and CVE-2026-65634 are the source records.

What breaks

On CVE-2026-89422, tls_client_connection_1_3:handle_server_hello/2 passes a received pre_shared_key extension into tls_gen_connection_1_3:handle_resumption/2, which sets resumption = true on presence alone without checking that the client offered a PSK. Meanwhile tls_handshake_1_3:get_pre_shared_key/4 falls back to the all-zero "no PSK" value and keys the handshake with the ordinary non-PSK schedule, so the attacker's own ephemeral key is enough. The resumption flag then routes maybe_resumption/1 straight to wait_finished, skipping the certificate-handling states.

The default recommended client config is in scope: {verify, verify_peer} with trusted cacerts, TLS 1.3 enabled and preferred, and default session_tickets = disabled. The session_tickets modes manual and auto are equally affected whenever the client has no ticket to offer, including every first connection to a host. Any consumer of ssl:connect that negotiates TLS 1.3 is exposed, including httpc over HTTPS, database and messaging client libraries, and TLS distribution clients.

Application-visible clues on an affected connection: ssl:peercert/1 returns {error, no_peercert} despite verify_peer, and ssl:connection_information/2 reports {session_resumption, true} for a client that never held a ticket.

On CVE-2026-68956, an authenticated SSH client can open many session channels that never get a shell, exec, or subsystem handler. Those idle channel records still land in the ETS channel cache, but max_channels only counts supervisor children, so the option does not bound the attack. One authenticated connection can grow memory until the emulator exits.

On CVE-2026-65634, the BER/PER/JER OBJECT IDENTIFIER decoders accumulate an unbounded base-128 subidentifier with quadratic work. A crafted OID (roughly 262 KB of continuation bytes in the advisory's example) can burn about 13 seconds of CPU on typical hardware. The decoder is generated into modules that parse X.509, including OTP-PUB-KEY via public_key:pkix_decode_cert/2, and it runs before signature or trust-chain verification. Default TLS clients (always parse the server cert) and mTLS servers (parse client certs) are exposed.

Who is not in scope

TLS clients restricted to TLS 1.2 via {versions, ['tlsv1.2']} are not affected by CVE-2026-89422 (they never hit the TLS 1.3 client path).
OTP builds already on 29.1.1, 28.5.0.7, or 27.3.4.18 (and later on those trains) are patched for this cluster.
CVE-2026-68956 needs a successfully authenticated SSH session; it is not an unauthenticated internet worm. Network-restricted SSH daemons shrink exposure but do not replace the upgrade.
CVE-2026-65634 is a CPU denial of service during cert/OID parse, not a certificate forgery or auth bypass by itself.

How to fix

Upgrade Erlang/OTP to one of:

OTP 29.1.1
OTP 28.5.0.7
OTP 27.3.4.18

Matching application versions called out by ERLEF:

ssl: 11.7.7 / 11.6.0.6 / 11.2.12.13
ssh: 6.0.6 / 5.5.2.6 / 5.2.11.13
asn1: 5.5.2 / 5.4.3.1 / 5.3.4.3

Rebuild and redeploy every BEAM release, container image, and host package that embeds OTP (Elixir releases, RabbitMQ nodes, CouchDB, ejabberd, custom ssl:connect clients, and SSH daemons). There is no configuration that both keeps TLS 1.3 and mitigates CVE-2026-89422. The only temporary workaround is forcing TLS 1.2 on affected clients until you can patch.

For SSH while you roll: restrict who can authenticate, set a finite max_sessions, and rate-limit connections. Do not rely on max_channels for the idle-session bug.

One concrete check

erl -noshell -eval 'io:format("~s~n", [erlang:system_info(otp_release)]), halt().'
# and for the full patch level on modern OTP:
erl -noshell -eval '{ok, V} = file:read_file(filename:join([code:root_dir(), "releases", "RELEASES"])), io:format("~s~n",[V]), halt().'

Or check the package you actually ship:

rabbitmqctl status | head
# Elixir releases often embed OTP; inspect the release's erts / OTP version
cat _build/prod/rel/*/releases/*/OTP_VERSION 2>/dev/null || true

If you are below 27.3.4.18 / 28.5.0.7 / 29.1.1 on those trains, treat TLS 1.3 clients and ASN.1/TLS cert parse surfaces as exposed until the bump lands.

What this is not

This is not remote code execution, not an unauthenticated worm across the open internet, and not a bug that only hits exotic PSK ticket configs. It is a TLS 1.3 client authentication bypass under default settings, plus two High DoS siblings fixed on the same OTP patch train.

References

Temporal write access can run shell on your Worker Service host

Michael Kantor — Mon, 21 Sep 2026 13:27:22 +0000

Originally published at HOL

Anyone with write access in a single Temporal namespace can make the Worker Service host run a shell command of their choosing. Temporal published CVE-2026-89139 today (CVSS 4.0 8.7 High). The Worker Controller's built-in subprocess compute provider takes the program and argv from the caller's worker-deployment request, not from operator config, and runs it immediately on the Worker Service machine. That process holds persistence credentials for every namespace and the cluster TLS material, so one namespace write reaches the whole cluster.

Ship the same upgrade for the sibling admin-callback bug CVE-2026-87858 (CVSS 4.0 7.2 High): a caller-controlled source header on a completion callback can retarget the History service at the internal frontend as system administrator. Do not open a second article for that train. This is the operator write-up; the HOL Guard evidence packs for CVE-2026-89139 and CVE-2026-87858 are the source records.

What breaks

On CVE-2026-89139, Temporal Server 1.31.0 through before 1.31.3 ships a Worker Controller Instance module inside the Worker Service. That module registers a compute provider named subprocess. An authenticated caller with only a write role in one namespace can set a worker deployment version whose scaling group uses that provider. The handler validates the spec, then invokes every provider with the invoke strategy right away. No scaling event, task arrival, or unusual request sequence is required. The official temporal-server binaries and container images include the provider.

The only gate that can keep subprocess unreachable is the per-namespace dynamic config workercontroller.compute_providers.enabled. Its default is an unset list, and the allowlist check is skipped when the value is unset, so every registered provider is permitted. The separate workercontroller.enabled flag defaults to false and does not gate this path. Temporal confirmed an affected release with that setting never present anywhere in dynamic config is still exposed.

On CVE-2026-87858, History decided whether a Workflow completion callback was "internal" by reading a caller-supplied HTTP header named source. A namespace writer who can attach a callback whose host matches component.callbacks.allowedAddresses, and who can put a non-empty source header on it (releases 1.30.0+), causes History to rewrite only scheme and host and send the caller's path, query, and body to the local frontend client. Where an internal frontend is deployed with its HTTP API enabled, that client authorizes every request as system administrator. Confirmed effects include terminating Workflows in other namespaces, registering namespaces, changing another namespace's config, and deleting another namespace and its Workflows. The same routing exists in both HSM and CHASM callback delivery. Releases 1.25.0 through 1.29.7 need the header to exactly match a configured cluster ID (harder). Upstream patches: PR 12021 (auto-scaled-workers bump for the subprocess fix), auto-scaled-workers PR 129, and PR 11965 (make Nexus callback source header inspection opt-in via callback.inspectSourceHeader, default false).

Who is not in scope

You are not in the CVE-2026-89139 blast radius if your Temporal Server is older than 1.31.0, or you are already on 1.31.3 / 1.32.0+, or the Worker Service is not running (non-default topologies only), or every namespace's workercontroller.compute_providers.enabled is set to an explicit list that omits subprocess. Deployments with no authorizer already grant every caller every namespace, so they have no namespace boundary for this bug to cross. For CVE-2026-87858, stock static topology without an internal frontend HTTP port, or an empty component.callbacks.allowedAddresses (the default denies all external callback URLs), keeps the admin retarget closed. Temporal Cloud is a separate product; this write-up is about self-hosted Temporal Server.

What this is not

Neither CVE is unauthenticated internet RCE. Both need an authenticated Temporal principal with namespace write. CVE-2026-89139 is host command execution on the Worker Service under the server process account. CVE-2026-87858 is admin-equivalent state changes through the internal frontend, not a free remote shell by itself. Neither is listed on CISA KEV as of this writing.

One operator check

On every self-hosted cluster, run the server binary or image tag check first:

temporal-server --version
# or
docker inspect --format '{{.Config.Image}}' temporal-frontend

Treat 1.31.0, 1.31.1, and 1.31.2 as CVE-2026-89139-exposed until you are on 1.31.3 or 1.32.0. For the callback sibling, treat 1.30.0 through before 1.30.7 and 1.31.0 through before 1.31.3 the same way; fixed trains are 1.30.7, 1.31.3, and 1.32.0.

Then confirm the dangerous defaults are not still live while you schedule the upgrade:

# dynamic config (per namespace). Unset = every compute provider allowed, including subprocess.
# Prefer an explicit allowlist that omits subprocess until you patch.
# workercontroller.compute_providers.enabled

callback allowlist empty by default (deny). Non-empty + internal-frontend httpPort > 0 = 87858 exposure window.
component.callbacks.allowedAddresses
services.internal-frontend.rpc.httpPort

To look for a subprocess config already attached, call DescribeWorkerDeploymentVersion for each worker deployment version in each namespace and check whether any scaling group's compute provider type is subprocess. For callbacks already attached, DescribeWorkflowExecution returns registered completion callbacks. Note the frontend HTTP API logs method and URL at debug only, so missing log lines are not proof the admin path was unused.

How to fix

Upgrade Temporal Server to 1.31.3 (or 1.30.7 on the 1.30 train, or 1.32.0+):

# Helm example. Pin the chart/app version that ships temporal-server 1.31.3 or 1.32.0.
helm upgrade temporal temporalio/temporal --version <chart-with-1.31.3-or-1.32.0>

Container
Use the official image tags that embed temporal-server 1.31.3 / 1.30.7 / 1.32.0

Release notes: v1.30.7, v1.31.3, v1.32.0. After upgrade, re-check temporal-server --version, confirm no worker deployment version still advertises provider type subprocess unless you intentionally allow it post-patch, and leave callback.inspectSourceHeader at its patched default (false) unless you are in a documented mixed-version escape hatch that still needs legacy HTTP worker callbacks.

References

NVD CVE-2026-89139 (CVSS 4.0 8.7 High)
NVD CVE-2026-87858 (CVSS 4.0 7.2 High)
temporal PR 12021 / auto-scaled-workers PR 129
temporal PR 11965 (callback source header opt-in)
HOL Guard packs: CVE-2026-89139, CVE-2026-87858

BREAKING: OpenShift console Devfile API lets anyone SSRF your cluster

Michael Kantor — Fri, 18 Sep 2026 22:51:38 +0000

Originally published at HOL

Anyone who can reach your OpenShift console Route can POST to the Devfile parser with no login, and the console pod will fetch internal URLs and chew memory until it falls over. Red Hat published CVE-2026-75885 today as Important (preliminary CVSS 9.3, CWE-918). The hole is unauthenticated access to /api/devfile/ and /api/devfile/samples/ in the OpenShift console (bridge). There is no RHSA and no Fixed In Version yet. Restrict who can reach the console Route now, and watch access.redhat.com for the errata.

This is the operator write-up. The HOL Guard evidence pack for CVE-2026-75885 is the source record. Do not open a second article for the authenticated Dev Console webhook SSRF sibling CVE-2026-50236; that one needs a login. This one does not.

What breaks

Red Hat’s advisory: unauthenticated access to the Devfile endpoints lets a remote attacker send crafted Devfile payloads. The console pod then makes requests to internal services (SSRF) and can reflect partial responses. Repeated large requests without a content length can drive unbounded memory growth and DoS.

Bugzilla 2517885 (status NEW, Fixed In Version empty) is more specific. In pkg/server/server.go, /api/devfile/ and /api/devfile/samples/ are registered with handleFunc() and are not wrapped in authHandler / authHandlerWithUser the way other /api/* routes are. DevfileHandler decodes an arbitrary JSON body and calls ParseDevfileAndValidate. The Devfile library resolves parent.uri, Dockerfile.uri, and remote plugin references over HTTP from the console pod. There is no MaxBytesReader / body size limit. Partial response bytes show up in the parser error string (partial-read SSRF). The reporter reproduced this on an OCP 5.0 nightly. Upstream tree: openshift/console.

Red Hat scores it CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L (9.3 Important), marks mitigation as not available under their Product Security criteria, and notes scores are preliminary. Impact in plain terms: an unauthenticated caller who can hit the console Route can use the console pod as a proxy into the cluster network and can DoS the console process with large bodies.

Who is not in scope

Clusters where the OpenShift console Route is not reachable from the attacker (strict network policy, private console only, no public Route) remove the unauthenticated blast radius for this CVE, but that is exposure control, not a patch. Installs that do not run the OpenShift console / bridge are out of scope. Authenticated-only Dev Console webhook SSRF tracked as CVE-2026-50236 is a different bug with a login requirement; do not treat a fix for one as coverage for the other. Non-OpenShift Kubernetes dashboards (vanilla kube-dashboard, Rancher UI, etc.) are not this CVE.

How to check

From a host that can reach the console Route, without a session cookie or OAuth token, probe whether the Devfile endpoint accepts an unauthenticated POST (expect a parser error JSON, not a 401/403 redirect to login):

# Replace CONSOLE with your console Route base URL (no trailing slash)
# A 401/403/login redirect is healthy. A 200/4xx parser body without auth is the bad path.
curl -sk -o /tmp/devfile-probe.body -w "HTTP %{http_code}\n" \
  -X POST "$CONSOLE/api/devfile/" \
  -H "Content-Type: application/json" \
  -d '{"content":"schemaVersion: 2.2.0\nmetadata:\n  name: probe\n"}'

Also confirm which console image your cluster runs

If the POST returns application JSON from the Devfile parser with no auth challenge, treat the Route as exposed to CVE-2026-75885 until Red Hat ships a console build that wraps those routes in auth and caps body size. Keep the probe payload tiny and stop after one request; do not load-test production.

How to fix

There is no public RHSA / Fixed In Version yet (Bugzilla 2517885 still NEW with an empty Fixed In Version field as of this writing). Red Hat lists mitigation as not available under their criteria. Until errata lands:

# 1) Restrict who can reach the console Route (NetworkPolicy / ingress / private API only)
# 2) Watch for the RHSA on the CVE page, then upgrade the console operator / console image
#    https://access.redhat.com/security/cve/CVE-2026-75885
#
# After an RHSA ships, apply the errata the usual way for your OCP train, for example:
#   oc adm upgrade --to=<errata-recommended-version>
# or follow the RHSA package list for the console image digest.
#
# Re-run the unauthenticated POST probe above and confirm you get auth failure, not parser output.

Do not invent a version number. When Red Hat publishes Fixed In Version / RHSA, upgrade that build and re-check the probe. Interim control is network exposure of the console Route, not a config flag named in the advisory.

What this is not

This is not remote code execution on the cluster and not a claim that every OpenShift install on the public internet is already owned. It is unauthenticated SSRF plus resource-exhaustion DoS through two Devfile API routes on the console, with Scope Changed and Confidentiality High on Red Hat’s preliminary 9.3. It is not the authenticated Dev Console webhook SSRF (CVE-2026-50236). It is not “wait for NVD analysis before acting”: if your console Route is reachable, shrink exposure today and watch for the RHSA.