DEV Community: Diego Diaz

Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores

Diego Diaz — Sun, 06 Sep 2026 19:17:00 +0000

On September 4, 2026 attackers began exploiting a new, unpatched vulnerability in Magento Open Source and Adobe Commerce that allows unauthenticated remote code execution. The flaw, dubbed StyleSmuggler by Dutch e‑commerce security firm Sansec, lets malicious actors run arbitrary PHP code on the victim’s server and install a persistent backdoor – all without needing any credentials.

The vulnerability was first reported by CyberSecurityNews, which highlighted that the attack chain can drop a statically linked Rust binary (~1.9 MB) masquerading as a kernel worker thread.

Recorded Future’s H1 2026 malware trends report notes the rise of supply‑chain exploits and zero‑days in e‑commerce platforms, emphasizing the threat of trusted‑tool abuse.

Sansec reproduced the full attack chain on clean installations of Magento 2.4.7, 2.4.8 and 2.4.9, confirming that all current versions of Magento Open Source and Adobe Commerce are vulnerable. The first victim was running 2.4.6‑p15 with the July and August 2026 security patches applied, demonstrating that even fully patched stores were compromised.

Adobe has not yet issued a CVE identifier, advisory, or patch as of September 6, 2026, and its security bulletin still ends on the August 11 update.

Mitigation steps include: disable GraphQL temporarily for stores that do not rely on headless front‑ends; audit var/report and var/log/system.log for the marker string used by Sansec; disable proc_open, mount temporary directories with noexec, and enforce strict file permissions; monitor for suspicious cron entries writing to /var/spool/cron/crontabs and for processes named [kworker/u:8:0] running under the web‑user account; apply any unofficial patches released by the community while awaiting an official Adobe fix.

Adobe’s next scheduled security release is set for September 8, 2026, but the company has not confirmed whether it will address StyleSmuggler. Until then, store owners should harden their environments and monitor logs closely.

Next.js Patches Critical AVIF and Windows Path Traversal Flaws Enabling Unauthenticated RCE

Diego Diaz — Thu, 27 Aug 2026 18:17:01 +0000

What Happened

Vercel released security patches for two critical‑severity vulnerabilities in the Next.js web framework, both allowing unauthenticated remote code execution. One flaw is exploitable via specially crafted AVIF image files, the other via a path‑traversal issue on Windows file systems.[The Hacker News]

Technical Analysis

The Windows path traversal, tracked as CVE-2026-75604 (CVSS 9.0), affects Next.js applications that use both the Pages Router and App Router without Cache Components on a Windows filesystem. No workaround exists; upgrade immediately if you host on Windows.[Vercel advisory]

The AVIF flaw stems from a heap buffer overflow in the libheif library used by the sharp image processing package. The vulnerability (GHSA‑2xp9‑vwfh‑vxw4, CVSS 9.5) allows remote code execution when Next.js processes a malicious AVIF image.[Next.js advisory] The underlying issue is detailed in the libheif advisory (GHSA‑g89c‑p67h‑r497). All libheif versions through v1.23.1 are affected.

Impact

Any Next.js app running on Windows that uses the Pages or App Router may be compromised without authentication. Similarly, any app that processes AVIF images with sharp is vulnerable, regardless of operating system.

How to Protect Yourself

Upgrade to Next.js 15.5.24 (LTS) or 16.3.3 (Active LTS) released on August 25 2026. Use npm install next@15.5.24 or npm install next@16.3.3.
If you host on Vercel, the platform has already applied the patches – no action required.
Ensure the sharp dependency is updated to a version that bundles a fixed libheif (≥ v0.33.2).
Audit your deployment for Windows‑specific path handling and mitigate any custom file‑system code.

Mirage2FA Phishing-as-a-Service Hijacks Microsoft 365 Sessions at Scale

Diego Diaz — Tue, 25 Aug 2026 22:17:01 +0000

What Happened

The Mirage2FA campaign emerged as a large‑scale phishing‑as‑a‑service (PhaaS) platform that targets Microsoft 365 accounts. By exploiting legitimate login flows, the toolkit enables attackers to bypass multi‑factor authentication (MFA) and steal authenticated session cookies. Recent research shows that the campaign has affected more than 4,500 organizations across the US and EU, with roughly 48% of targeted email addresses potentially compromised.source

Technical Analysis

Mirage2FA operates through an adversary‑in‑the‑middle (AiTM) technique. Victims receive malicious HTML or SVG attachments that render a fake Microsoft 365 login page. When the user enters credentials and completes the MFA challenge, the toolkit proxies the data to the real Microsoft authentication service over a persistent WebSocket channel. The legitimate authentication response, including session tokens, is intercepted and streamed back to the attacker, who then captures the authenticated session cookie.source This approach allows the attacker to hijack an active session without needing to crack the second factor directly.

Detailed sandbox analysis by ANY.RUN revealed that the malicious payloads employ multiple obfuscation layers – Base64 encoding, XOR with key 0xAD, and eval‑based execution – to hide the JavaScript loader that fetches second‑stage scripts from attacker‑controlled infrastructure (e.g., user.cheacker.store). The loader then initiates the WebSocket tunnel that carries the authentication flow.source

Who’s Affected

The impact spans a wide range of industries, with the technology sector representing the largest share (≈19% of victims), followed by manufacturing and education. Geographic analysis shows that 63.7% of compromised organizations are based in the United States, while the remaining victims are distributed across India, Singapore, the United Kingdom, Canada, Saudi Arabia, South Africa, and other regions.source The campaign has generated more than 9,000 potential compromise events, including over 4,500 cookie‑theft incidents, 3,000 password or MFA code captures, and 1,300 SSO logins.

How to Protect Yourself

Enforce Phishing‑Resistant Authentication: Deploy hardware security keys (FIDO2) or password‑less authentication methods that do not rely on credential entry in a web form.
Monitor Session Activity: Enable Continuous Access Evaluation (CAE) in Microsoft Entra ID to automatically invalidate compromised tokens.
Revoke Stolen Sessions Immediately: Upon detection of suspicious activity, force password resets, invalidate refresh tokens, and audit OAuth grants.
Implement Advanced Email Filtering: Block HTML/SVG attachments and sandbox suspicious files before they reach end users.
Educate Users on AiTM Threats: Train staff to recognize subtle differences in login pages, such as mismatched URLs or unexpected CAPTCHA screens.

The Sable Angle

At Sable we help startups and enterprises harden their identity infrastructure. Our penetration‑testing‑as‑a‑service includes simulated AiTM attacks to verify that MFA implementations resist session‑hijacking techniques like those used by Mirage2FA. Learn more about our pricing and see case studies in our research hub.

By integrating continuous monitoring, hardware‑based authentication, and proactive threat‑hunting, organizations can reduce the attack surface that Mirage2FA exploits and protect critical data stored in Microsoft 365.source

Active Oracle WebLogic Flaw Exposes Critical Data – CVE‑2026‑21962

Diego Diaz — Tue, 25 Aug 2026 18:17:04 +0000

What Is CVE‑2026‑21962?

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE‑2026‑21962 to its Known Exploited Vulnerabilities (KEV) catalog on August 25, 2026. The flaw affects Oracle HTTP Server and the Oracle WebLogic Server Proxy Plug‑in, granting an unauthenticated attacker remote code execution via a crafted HTTP request. The vulnerability carries a CVSS score of 10.0—the highest severity rating.source
Oracle CPU Jan 2026 patch CISA KEV catalog CISA KEV catalog

Why Is This Flaw Critical?

Oracle WebLogic is a core component for many enterprise Java applications. Compromise of the proxy plug‑in can lead to:

Unauthorized creation, deletion, or modification of critical data.
Full system takeover on any server running the vulnerable proxy.
Lateral movement within corporate networks, as the exploit works over plain HTTP. These capabilities make the vulnerability a high‑value target for ransomware groups and nation‑state actors.source

Evidence of Active Exploitation

Multiple threat‑intel feeds have recorded exploitation attempts:

GreyNoise observed traffic from IP 193.24.123[.]42 targeting the vulnerable endpoint in February 2026.
CloudSEK’s honeypot captured exploitation attempts against CVE‑2026‑21962 as well as several legacy WebLogic RCE flaws (e.g., CVE‑2020‑14882).source The persistence of attacks across multiple CVEs underscores a concerted effort to compromise WebLogic environments.

Recommended Mitigations

Organizations should act immediately:

Patch Immediately: Apply Oracle’s January 2026 security update for CVE‑2026‑21962.source
Network Segmentation: Restrict inbound HTTP access to WebLogic servers to trusted subnets or VPNs.
Web Application Firewall (WAF): Deploy rule sets that block the malformed HTTP payloads used in the exploit.
Monitor Indicators: Watch for traffic from the known malicious IP and for unusual requests to the WebLogic proxy endpoint.
Incident Response: If compromise is suspected, isolate affected hosts, capture memory dumps, and perform forensic analysis for potential data exfiltration.

Conclusion

CVE‑2026‑21962 is a perfect storm: a critical CVSS 10.0 rating, unauthenticated remote code execution, and clear evidence of active exploitation. Prompt patching, strict network controls, and vigilant monitoring are essential to prevent data breaches and ransomware impact.source

Critical GitLab GraphQL Flaw (CVE‑2026‑19478) Enables Remote Deletion of Public Projects

Diego Diaz — Mon, 24 Aug 2026 02:17:01 +0000

What Happened

On August 17 2026 GitLab released an emergency patch for a critical vulnerability tracked as CVE‑2026‑19478. The flaw is a code‑injection issue in the GraphQL API that permits unauthenticated attackers to issue specially crafted directives that delete or modify public projects and associated user data. The vulnerability affects self‑managed GitLab Community Edition (CE) and Enterprise Edition (EE) installations running versions 18.2 < 18.11.11, 19.0 < 19.0.8, 19.1 < 19.1.6 and 19.2 < 19.2.4. GitLab.com and GitLab Dedicated were patched earlier and are not vulnerable. The flaw was responsibly disclosed by researcher hiimguardian via the HackerOne bounty program.

Technical Analysis

The vulnerability resides in improper authorization checks within GitLab's GraphQL layer. An attacker can send a GraphQL directive – a server‑side instruction – that bypasses normal access controls and triggers destructive mutations without any authentication (CVSS score 9.4). Because the GraphQL endpoint processes the malicious directive before any permission validation, the request can delete entire repositories, forge merge records, or ban maintainers. The affected code path is present in all self‑hosted versions from 18.2 up to, but not including, 18.11.11 and the 19.x series listed above. No new database migrations are required, and the patch can be applied with zero downtime on multi‑node deployments.

Who Is Affected

Any organization that runs a self‑managed GitLab instance accessible over the internet – including on‑premise installations, private cloud deployments, and CI/CD pipelines – is at risk. Public projects, which are often used for open‑source collaboration, are especially exposed because they can be accessed without authentication. According to watchTowr’s honeypot data, active exploitation was observed within minutes of disclosure, confirming that attackers are already scanning for exposed GraphQL endpoints. Enterprises that host sensitive source code, CI configuration, or proprietary artifacts in public repositories could lose years of development work and suffer downstream supply‑chain impact if an attacker removes or rewrites project history.

How to Protect Yourself

Immediately upgrade all self‑managed GitLab instances to the patched versions: 18.11.11, 19.0.8, 19.1.6 or 19.2.4. The patches were released on Aug 17 2026 and are available via the official GitLab package repositories.
If an upgrade cannot be performed instantly, block unauthenticated access to the GraphQL endpoint (/api/graphql) at the perimeter firewall or via a reverse‑proxy rule. Only authenticated users should be allowed to reach this endpoint.
Disable public projects or restrict them to authenticated members until the patch is applied. This removes the attack surface that the vulnerability leverages.
Search web server logs for requests containing the string @gl_introduced – a marker identified by watchTowr as indicative of exploitation attempts. Investigate any matching entries for suspicious activity.
Enable GitLab’s built‑in security alerts and configure email notifications for GraphQL‑related errors. Regularly review audit logs for unexpected mutation events.

The Sable Angle

At Sable we specialize in turning high‑impact vulnerabilities into actionable threat‑intel for our clients. Our Red‑Team labs have reproduced CVE‑2026‑19478 against a range of hardened GitLab deployments, demonstrating how quickly an unauthenticated attacker can erase an entire codebase. By integrating the patch‑validation workflow into our continuous‑delivery pipeline, we ensure that every GitLab instance we manage stays ahead of the exploit curve.

Beyond remediation, Sable offers a post‑mortem service that maps deleted repositories to downstream dependencies, helping organizations assess the ripple effect on CI pipelines, container images, and downstream services. Reach out to our security consulting team for a tailored hardening guide or to schedule a rapid‑response engagement. Learn more about our offensive research capabilities at /research/gitlab-cve-19478 and explore our managed‑security offering at /pricing.

Microsoft Entra ID Flaw (CVE-2026-69836) Exploited in the Wild – Critical Remote Code Execution

Diego Diaz — Fri, 21 Aug 2026 22:17:01 +0000

What is the vulnerability?

Microsoft disclosed a maximum‑severity deserialization flaw in its cloud identity service Entra ID (formerly Azure AD) tracked as CVE-2026-69836. The vulnerability scores a CVSS 10.0 and allows an unauthenticated attacker to execute arbitrary code on the service[1].

How was it exploited?

Microsoft confirmed the flaw was already being exploited in the wild before the patch was released. While details of the attack chain are scarce, the advisory notes that the bug enables remote code execution without any user interaction or privileges[2] The Hacker News.

Impact and scope

Entra ID underpins identity and access management for millions of Microsoft customers, protecting access to Azure services, Office 365, and countless third‑party applications. Successful exploitation could let attackers impersonate any identity, compromise data, and disrupt services across the Microsoft cloud ecosystem[3] The Register.

Mitigation and response

Microsoft states the vulnerability has been fully mitigated on its side, requiring no action from customers. The company credits principal security engineer Robert Fitzpatrick for discovering and reporting the issue. Administrators should monitor Microsoft’s security advisories for any follow‑up guidance and ensure Entra ID configurations follow the principle of least privilege.

Critical MLflow SSRF Vulnerability (CVE-2026-64849) Enables Massive Cloud Credential Theft

Diego Diaz — Wed, 19 Aug 2026 02:17:01 +0000

What Happened

On August 18, 2026, multiple security researchers reported that a new unauthenticated Server‑Side Request Forgery (SSRF) vulnerability, identified as CVE‑2026‑64849, is being actively exploited against the popular open‑source AI platform MLflow. The flaw allows an attacker to force a vulnerable tracking server to make arbitrary HTTP requests to internal cloud metadata services, exfiltrating highly privileged cloud credentials and secrets. In parallel, a second critical issue (CVE‑2026‑25895) affects the FUXA SCADA/ HMI tool, but the focus of this article is the MLflow SSRF chain.

WatchTowr’s global Attacker Eye honeypot network observed exploitation attempts within hours of the CVE assignment, confirming that threat actors are already scanning for exposed MLflow instances and stealing credentials at scale.

Technical Analysis

MLflow’s tracking server, when deployed without mandatory authentication, exposes a /api/2.0/mlflow/webhooks/{id}/test endpoint. An unauthenticated POST request to this endpoint triggers the platform’s webhook delivery logic, which reflects the full upstream HTTP response back to the caller. The original MLflow code validates only the initial destination URL, but it follows HTTP redirects without re‑validating the final address. By supplying a benign URL that redirects to a cloud metadata endpoint, an attacker can retrieve temporary IAM role credentials, OAuth tokens, and other sensitive configuration data from cloud providers.

The vulnerability impacts all MLflow versions prior to 3.15.0. The flaw is amplified on cloud‑hosted deployments where the MLflow server runs with high‑privilege instance roles, giving attackers unrestricted access to the surrounding cloud environment. Exploit code published on public GitHub repositories demonstrates the attack in under 30 lines of Python, leveraging the requests library to automate mass exploitation.

Who’s Affected

Any organization that runs an internet‑facing or improperly firewalled MLflow tracking server with default authentication settings is at risk. The issue is especially dangerous for teams that embed cloud credentials (AWS access keys, Azure service principals, GCP service accounts) directly into the MLflow environment for model training pipelines. According to watchTowr, dozens of public MLflow instances were observed scanning Azure, AWS, and GCP metadata services within the first 24 hours after disclosure. Enterprises in finance, healthcare, and autonomous vehicle development that rely on large‑scale AI training are prime targets because the stolen credentials can be leveraged for lateral movement, data exfiltration, and ransomware deployment.

How to Protect Yourself

Upgrade Immediately: Apply the official fix released in MLflow v3.15.0, which adds strict validation of both the initial URL and any subsequent redirects, and disables unauthenticated webhook testing by default.
Enforce Authentication: Require authentication (OAuth, LDAP, or token‑based) for all MLflow API endpoints. Disable public exposure of the Tracking Server unless absolutely necessary.
Network Segmentation: Place MLflow servers in isolated subnets and block outbound access to cloud metadata endpoints.
Audit Logs: Review server access logs for unexpected POST requests to /api/2.0/mlflow/webhooks/. Look for outbound connections to internal metadata services.
Rotate Compromised Credentials: If you suspect exploitation, immediately revoke and rotate any cloud IAM roles or service‑account keys associated with the affected MLflow instances.

The Sable Angle

At Sable we specialize in securing AI and data‑science pipelines. Our team has built custom hardening modules that integrate directly into MLflow, enforcing zero‑trust policies and automated secret‑management rotation. By deploying our secure‑MLflow bundle, you can protect your model‑training workloads from SSRF attacks while maintaining full workflow flexibility.

For organizations looking to audit their AI stack, we offer a free assessment that maps cloud‑credential exposure pathways across your ML lifecycle. Contact us through the Sable research portal to learn more.

Critical GitLab GraphQL Flaw (CVE-2026-19478) Allows Unauthenticated Deletion of Public Projects

Diego Diaz — Tue, 18 Aug 2026 18:17:01 +0000

Overview

On August 17, 2026, GitLab released emergency patches for a critical GraphQL vulnerability tracked as CVE-2026-19478. The flaw allows unauthenticated attackers to remotely modify or delete public projects and user data on self-managed installations. The vulnerability has been assigned a CVSS score of 9.4 (Critical), making it one of the most severe security issues observed in GitLab this year.

The Hacker News

Technical Details

The issue resides in GitLab's GraphQL API layer. A crafted GraphQL directive can be sent to a vulnerable instance without any credentials or user interaction, triggering a code-injection path that ultimately executes destructive operations on public projects. The attack vector works over the network (AV:N), requires low complexity (AC:L), and impacts integrity (I:H) and availability (A:H) while confidentiality impact is low (C:L). The flaw affects all self-managed Community Edition (CE) and Enterprise Edition (EE) versions from 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4.

SecurityAffairs

Impact

Successful exploitation enables an attacker to:

Delete public repositories, removing source code, CI/CD pipelines, and release artifacts.
Modify project metadata, potentially injecting malicious files or altering permissions.
Exfiltrate or corrupt user data stored within public projects.

Because no authentication is required, any internet-facing GitLab instance is at risk. Automated scanners can probe for the vulnerable GraphQL endpoint, making large-scale exploitation feasible.

Rescana

Affected Versions & Patch Release

GitLab patched the issue on August 17, 2026 and released the following patched versions:

19.2.4
19.1.6
19.0.8
18.11.11

Self-managed deployments must upgrade immediately. GitLab.com and GitLab Dedicated are already on the patched versions and require no action. No new database migrations are required, and multi-node clusters should not experience downtime.

Tech Times

Mitigation & Recommendations

Upgrade all self-managed GitLab instances to the latest patched version (18.11.11, 19.0.8, 19.1.6, or 19.2.4) immediately.
Restrict external access to the GraphQL endpoint (/api/graphql) using firewall rules or a reverse-proxy that enforces authentication for public-facing services.
Monitor audit logs for unexpected project deletions or modifications. Look for GraphQL mutation activity without an authenticated session.
Apply any future security updates promptly; consider enabling GitLab’s auto-update channel for critical patches.
Review and reduce the exposure of public projects where possible, moving sensitive repositories to private visibility.

References

Critical SharePoint JWT Authentication Bypass CVE-2026-55040 Exploited in the Wild

Diego Diaz — Mon, 17 Aug 2026 02:17:01 +0000

What Happened

On August 13, 2026, threat actors began exploiting a newly disclosed Microsoft SharePoint vulnerability, identified as CVE-2026-55040, with a CVSS score of 9.1. The flaw resides in the JSON Web Token (JWT) validation pipeline, allowing unauthenticated attackers to bypass authentication and gain administrative privileges The Hacker News.

Technical Analysis

The vulnerability is rooted in four chained weaknesses within the SharePoint JWT handling code. First, the token validation routine disables the requirement for a cryptographic signature. Second, an attacker‑controlled certificate thumbprint (x5t) is resolved against SharePoint’s own Security Token Service (STS) certificate without verification. Third, issuer validation accepts unregistered certificates, and fourth, the final signature check only verifies that the field is non‑empty, not that it is cryptographically valid. These weaknesses allow a forged token to be accepted as legitimate, granting the attacker the ability to impersonate any SharePoint user, including site administrators Rapid7 Technical Analysis.

Who’s Affected

The flaw impacts on‑premises SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016. Shadowserver tracks over 8,500 publicly exposed SharePoint installations, many of which remain unpatched despite Microsoft’s July 2026 Patch Tuesday release. Exploitation attempts have been recorded from at least eight unique IP addresses across Hong Kong, Japan, the Netherlands, Taiwan, and the United States, with twelve total attempts since mid‑July, eight of which occurred on August 12‑13 alone TechTimes.

How to Protect Yourself

Apply Microsoft’s July 2026 Patch Tuesday update immediately to remediate CVE-2026-55040.
Restrict direct internet exposure of SharePoint servers; place them behind a Layer 7 reverse proxy that enforces authentication and inspects traffic.
Implement strict JWT validation policies: require signed tokens, validate issuer chains, and enforce certificate pinning for STS certificates.
Monitor authentication logs for anomalous token usage and unauthorized admin actions.
Leverage threat‑intelligence feeds (e.g., CISA, Defused) to stay aware of emerging exploits.

The Sable Angle

At Sable, we routinely assess SharePoint environments for misconfigurations and exploitability. Our offensive security team can simulate the JWT bypass chain to validate defenses and provide tailored hardening recommendations. Learn more about our SharePoint security audit services here and explore how Sable’s platform can automate continuous monitoring for similar authentication‑bypass patterns.

Cisco ASA and FTD Remote DoS Flaw Actively Exploited

Diego Diaz — Wed, 12 Aug 2026 20:17:01 +0000

What Happened

On August 12, 2026 Cisco disclosed that a high‑severity vulnerability (CVE-2026-20349, CVSS 8.6) in its Secure Firewall Adaptive Security Appliance (ASA) and Secure Firewall Threat Defense (FTD) software was being actively exploited in the wild. The flaw enables an unauthenticated attacker to send a crafted HTTP request to the Remote Access SSL VPN service, causing the device to reload and enter a denial‑of‑service (DoS) state. The Hacker News reported the advisory on the same day.

Technical Analysis

The root cause is insufficient error checking when processing HTTP requests targeting the Remote Access SSL VPN service. When the malicious request is received, the appliance crashes and automatically reloads, interrupting VPN connectivity for all users. Affected configurations include IKEv2 Remote Access VPN with client‑services, SSL‑VPN, and Zero Trust Network Access. The vulnerability impacts ASA versions 9.161, 9.181, 9.20, 9.22, 9.23, 9.24 and FTD version 7.0, with fixes released for each version. Details and version‑specific fixes are listed in Cisco’s advisory Cisco Security Advisory and also referenced in the Hong Kong CERT bulletin HKCERT.

Who's Affected

Any organization running the vulnerable ASA or FTD releases with the Remote Access SSL VPN service enabled is at risk. Large‑scale brute‑force attacks observed in early 2024 already targeted similar VPN services across many vendors, amplifying the impact of this flaw. Enterprises that expose VPN portals to remote employees, contractors, or partners are especially vulnerable. The issue has been added to the U.S. CISA Known Exploited Vulnerabilities (KEV) catalog, mandating federal agencies to patch by August 14, 2026.

How to Protect Yourself

Immediately apply Cisco’s hotfixes for the affected ASA and FTD versions. Patch links are provided in the advisory above.
Verify that the Remote Access SSL VPN service is disabled if not required. Use show running-config webvpn | include ^enable to confirm.
Enable multi‑factor authentication (MFA) for VPN logins to reduce the risk of credential‑theft attacks that often precede exploitation.
Monitor VPN logs for unusually high rates of authentication attempts or malformed HTTP requests and alert on spikes.
Consider segmenting VPN traffic on dedicated firewalls and applying rate‑limiting controls.

The Sable Angle

Our Red Team frequently exploits mis‑configured VPN appliances to gain initial footholds in target networks. The CVE‑2026‑20349 vector aligns with real‑world attack chains we have documented in our Sable research library. By automating crafted HTTP requests against vulnerable SSL‑VPN endpoints, we can trigger immediate service disruption, forcing defenders to divert resources.

While Sable does not advise intentional DoS attacks, understanding this flaw helps security teams harden their perimeter. Deploying the latest patches, disabling unnecessary VPN services, and applying strict authentication controls are proven defensive measures that mitigate both the denial‑of‑service risk and the broader lateral‑movement opportunities that follow initial compromise.

CISA Flags Langflow, Tomcat, and N-central Flaws as Actively Exploited (CVE‑2026‑9198, CVE‑2026‑34486, CVE‑2026‑18556)

Diego Diaz — Wed, 05 Aug 2026 21:17:00 +0000

What Happened

On August 5, 2026 the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added three flaws to its Known Exploited Vulnerabilities (KEV) catalog. The agency cited active exploitation in the wild for each entry:

CVE‑2026‑9198 (CVSS 9.8) – unauthenticated remote code execution in the AI workflow platform Langflow.
CVE‑2026‑34486 (CVSS 7.5) – missing encryption in Apache Tomcat that bypasses the EncryptInterceptor cluster component.
CVE‑2026‑18556 (CVSS 8.2) – authentication‑bypass in N‑able N‑central (partial fix later issued as CVE‑2026‑18577).

All three products are widely deployed in enterprise environments, making the combined threat surface massive.

Technical Analysis

Langflow RCE (CVE‑2026‑9198) stems from an insecure exec_globals parameter in the /validate endpoint. The backend deserializes untrusted user input via pickle.loads(), allowing attackers to execute arbitrary Python code without authentication. Affected versions range from 0.0.31 to 1.7.3; the issue was patched in 1.10.1 (July 2026). The KEV Intel service logged >220 exploitation attempts from 64 unique IPs starting June 27, 2026.

Tomcat Encryption Bypass (CVE‑2026‑34486) affects Apache Tomcat 9‑0‑117, 10‑1‑54, and 11‑0‑21. The EncryptInterceptor is intended to encrypt inter‑node messages, but a missing check allows crafted traffic to skip encryption entirely, exposing cluster communication to eavesdropping and tampering. This vulnerability was leveraged by a China‑based threat actor (aliases knaithe/KnYuan) using DeepSeek‑driven autonomous hacking to target internet‑exposed Tomcat instances.

N‑central Auth Bypass (CVE‑2026‑18556 / CVE‑2026‑18577) is an unauthenticated bypass of the web UI authentication flow, allowing attackers to obtain administrative sessions. The initial fix (CVE‑2026‑18556) was incomplete, prompting N‑able to release CVE‑2026‑18577 as a corrective patch. Both CVEs are now listed in KEV, indicating active exploitation.

Who’s Affected

Enterprises running any of the following are at risk:

Langflow deployments (often containerised AI pipelines) – especially those exposing the default /validate endpoint.
Apache Tomcat clusters in production (webapps, middleware, micro‑services).
N‑central remote‑management installations used by MSPs and internal IT teams.

Combined, these products protect billions of requests daily; a successful exploit can lead to full system compromise, credential theft, or lateral movement across internal networks.

How to Protect Yourself

Patch Immediately: Apply the latest Langflow 1.10.1 release, upgrade Tomcat to 9.0.118, 10.1.55, or 11.0.22, and install N‑central 2026‑18577 patches.
Restrict Network Exposure: Block external access to Langflow validation endpoints and Tomcat cluster ports behind a firewall or VPN. Use zero‑trust network segmentation.
Enable TLS & Authentication: Ensure Tomcat’s EncryptInterceptor is enabled with strong cipher suites, and enforce MFA on N‑central admin consoles.
Monitor for Exploitation Indicators: Look for unusual outbound connections from Langflow containers, unexpected Java deserialization errors in Tomcat logs, and anomalous admin‑session creations in N‑central.
Perform Post‑Patch Validation: Run vulnerability scanners (e.g., OpenVAS, Nessus) to confirm the patches are applied and no residual exploit code remains.

The Sable Angle

At Sable we specialise in hardening AI‑powered pipelines and legacy Java stacks. Our Langflow security audit uncovers hidden deserialization paths, and we can assist with automated Tomcat cluster hardening via our bespoke SecureCluster module. Contact us for a free triage of your AI‑workflow and Java infrastructure.

Critical RCE in Hugging Face LeRobot (CVE‑2026‑25874) Exposes Robotics Infrastructure

Diego Diaz — Wed, 05 Aug 2026 13:17:00 +0000

What Happened

On April 28, 2026, security researchers disclosed a critical remote code execution (RCE) flaw in Hugging Face’s open‑source robotics framework LeRobot. The vulnerability, tracked as CVE‑2026‑25874, carries a CVSS score of 9.3 (per The Hacker News) and effectively grants unauthenticated attackers the ability to run arbitrary system commands on any machine running a vulnerable LeRobot service.

Technical Analysis

The root cause lies in LeRobot’s async inference pipeline, where the pickle.loads() function is used to deserialize data received over unauthenticated gRPC channels. Because the server is started with add_insecure_port(), there is no TLS or authentication, allowing any network‑reachable actor to send a crafted payload to RPC handlers such as SendPolicyInstructions or SendObservations. When the malicious payload is processed, pickle.loads() executes the embedded code immediately, giving the attacker full system control (see the detailed proof‑of‑concept published by Chocapikk).

The flaw affects all LeRobot versions up to 0.5.1 – the latest stable release at the time of disclosure. A fix is slated for version 0.6.0, but it has not yet been released. The CVSS score of 9.8 is reported by Cyber Press, reflecting the severe impact on confidentiality, integrity, and availability.

Who’s Affected

LeRobot is widely adopted in AI‑powered robotics research and production. With over 24,000 stars on GitHub (as noted by CyberSecurityNews) and more than 58,000 community‑contributed datasets hosted on the Hugging Face Hub, the framework powers a range of deployments—from research prototypes to industrial robot controllers. Any organization that runs LeRobot’s async inference server on a publicly reachable network is at risk. The vulnerability also threatens downstream services that rely on LeRobot for policy computation, model serving, or robot control, potentially leading to data exfiltration, credential theft, and even physical safety hazards when compromised robots act on malicious commands.

How to Protect Yourself

Restrict Network Access: Bind the inference server to localhost or use a firewall to allow connections only from trusted internal hosts.
Enable TLS and Authentication: Switch from add_insecure_port() to add_secure_port() with proper TLS certificates, and enforce token‑based authentication on all gRPC endpoints.
Replace Pickle Deserialization: Migrate to safe serialization formats such as safetensors, JSON, or protobuf‑native fields. If pickle must be used, wrap calls with strict validation and remove any #nosec comments that silence linters.
Update Immediately: Apply the forthcoming patch in LeRobot 0.6.0 as soon as it is released. Until then, consider forking the repository and back‑porting the serialization fix.
Monitor for Exploitation: Watch for indicators of compromise such as unexpected grpc traffic, new processes executing under the inference service user, or abnormal filesystem changes in the LeRobot working directory.

The Sable Angle

At Sable we specialize in hardening AI‑driven infrastructure. Our team can help you audit your LeRobot deployment, replace unsafe deserialization with Sable‑Safetensors™, and implement zero‑trust network segmentation to keep your robotic fleets safe. Get in touch to run a free security assessment and ensure your AI pipelines are production‑ready.