What Is LiteLLM — and Why Does Its Compromise Matter?

LiteLLM is one of the most popular AI infrastructure packages on PyPI, used by startups, enterprises, and Indian IT shops alike to manage multi-LLM deployments, normalise API responses, and control cost routing across providers including OpenAI, Anthropic Claude, Google Gemini, AWS Bedrock, and Azure OpenAI. Because it sits directly in the data path between application code and AI providers, an LiteLLM installation typically has legitimate access to an organisation’s most sensitive tokens: provider API keys, cloud IAM credentials, database connection strings, and developer SSH keys.

That makes it an exceptionally high-value supply-chain target. When a developer runs pip install litellm — or when a CI/CD pipeline rebuilds a container — it trusts PyPI implicitly. In this attack, that trust was weaponised.

Attack Timeline: From Pipeline Compromise to Credential Theft

Technical Deep Dive: The Python Startup Hook Trick

What makes this attack particularly insidious is its execution mechanism. Most PyPI supply-chain attacks embed malicious code in the package’s __init__.py, so it only fires when the library is explicitly imported. This attacker went further.

According to Datadog Security Labs and Upwind, the malware injected three Python .pth startup hook files into the LiteLLM wheel packages. Python processes .pth files during interpreter initialisation — before any user code runs and before any specific library is imported. This means:

• The credential stealer activated on every Python process started on the affected machine, not just LiteLLM-specific workloads.
• Containers rebuilt from the poisoned Docker image would carry the payload into production environments.
• On Unix/Linux systems, the RAT component could fetch additional Python payloads and execute them remotely, though Microsoft’s analysis notes this second-stage activity was not confirmed in the wild.

Stolen data was POST-ed to www.litellm.dev — a typosquatted lookalike for the legitimate litellm.ai domain — making it easy for the payload to blend into network logs for teams that do not maintain strict egress allowlists.

How the Attacker Got In: GitHub OAuth Token Theft

LiteLLM’s own post-incident disclosure (published on docs.litellm.ai) states that the malicious release actions were performed through three LiteLLM engineers’ GitHub accounts, apparently using stolen GitHub CLI OAuth tokens. The attacker used these tokens to redirect the automated release workflow to a spoofed repository (Berri-AI/litellm, distinct from the legitimate BerriAI/litellm — note the capitalisation difference). Crucially, the official v1.107.0 git tag does not contain the malicious code; only the PyPI wheels and Docker images — built by the compromised pipeline — were poisoned.

This confirms a pattern seen repeatedly in 2026: CI/CD pipeline credentials are the new perimeter. Attackers do not need to compromise source code repositories when they can seize the keys to the build system itself.

What Was Targeted? A Credential Inventory

Microsoft’s Security Blog describes the stealer targeting “authentication material across developer tools, AI applications, cloud environments, browsers, and infrastructure.” In practice, that covers:

• AI provider API keys — Anthropic Claude, OpenAI, Cohere, Google AI Studio, Mistral
• Cloud IAM credentials — AWS Access Key/Secret, GCP service account tokens, Azure client secrets
• SSH private keys from ~/.ssh/
• Browser-stored credentials and session cookies
• CI/CD secrets — environment variables, .env files
• Container registry tokens (Docker Hub, GHCR)

For Indian enterprises routing LLM workloads through LiteLLM — especially managed service providers running multi-tenant AI gateways — the blast radius is substantial: a single compromised developer workstation or CI runner could expose credentials for dozens of downstream client environments.

What You Should Do Now: Sanjay Seth’s Expert Defensive Checklist

This is not a distant vendor problem. If you run Python-based AI workloads, act on this today.

1. Identify exposure immediately. Run pip show litellm and docker image inspect <image> on all development, CI, and production systems. Check build logs and container image histories for any pull of litellm==1.107.0 between 21 October 2026, 11:39 UTC and 13:23 UTC.
2. Rotate every credential. If a machine ran Python at any point while v1.107.0 was installed, treat all credentials it could access as compromised. Rotate API keys for all AI providers, cloud IAM keys, SSH keypairs, and container registry tokens. This is non-negotiable.
3. Pin your package versions. Add litellm==1.106.2 (the last safe release) to your requirements.txt or pyproject.toml and enforce version hashing (pip install --require-hashes) in CI pipelines.
4. Audit your egress traffic. Look for any POST requests to www.litellm.dev (note: .dev, not .ai) in firewall, proxy, or NDR logs from 21 October onward. Flag any match as a confirmed data exfiltration event.
5. Rebuild affected containers from scratch. Do not merely update the package inside an existing image. Any container built from the poisoned v1.107.0 base should be considered compromised at the filesystem level and rebuilt entirely.
6. Enable PyPI package signing verification. Adopt PyPI’s Trusted Publisher attestation model in your CI pipelines to validate that packages were built from the official repository’s workflow, not a spoofed one. This is the control that would have detected this attack.
7. Apply zero-trust to your AI supply chain. Just as you segment network access for production systems, segment your developer and CI environments behind zero-trust network policies. AI workload secrets should never be co-located with infrastructure credentials.

This is the third LiteLLM supply-chain compromise in 2026 alone (March, June, October). The pattern suggests this project — and open-source AI tooling broadly — is under sustained, targeted attack. Treat your AI dependency graph with the same rigour you apply to network perimeter controls.

Frequently Asked Questions

Am I affected if I didn’t upgrade on 21 October — I was pinned to 1.106.x?

If your requirements.txt or lockfile specifies a version below 1.107.0, and your CI pipeline respects that pin, you are likely not affected via PyPI. However, verify that no upstream container base image or transitive dependency silently pulled v1.107.0. The BleepingComputer analysis confirms that all seven 1.107.0 wheels were malicious, with no safe sub-variants.

Does this affect LiteLLM’s gateway/proxy (self-hosted) deployments?

Yes. The official Docker images for v1.107.0 were poisoned at build time, meaning self-hosted LiteLLM proxy containers built from the official image during the attack window are affected. According to Help Net Security, images on both Docker Hub and GitHub Container Registry were compromised. Any secrets passed into those containers — including your cloud provider API keys — should be rotated.

Is LiteLLM itself untrustworthy going forward?

Not necessarily. The core source code was not backdoored at the repository level — the official git tag for v1.107.0 is clean. The issue was a compromised build pipeline. LiteLLM has committed to publishing signed releases with provenance attestation going forward. Organisations deploying LiteLLM should require signed packages and monitor for future advisories. Three incidents in one year, however, does warrant a risk review of whether a single package should sit at the credential-rich centre of your AI stack.

Is there a CVE assigned to this incident?

As of the latest available reporting (23–24 October 2026), no CVE has been assigned to this specific supply-chain incident. The attack exploited compromised build pipeline credentials rather than a software vulnerability in LiteLLM’s code, which makes CVE assignment atypical. Monitor CISA’s Known Exploited Vulnerabilities catalog and LiteLLM’s official security blog for updates. The earlier June 2026 RCE chain (tracked as CVE-2026-42271) was a separate, distinct vulnerability in the LiteLLM gateway codebase.

AI adoption is accelerating across India’s enterprise sector, and LiteLLM sits at the nexus of that growth. An incident like this is a reminder that the AI supply chain deserves the same disciplined, layered defence that you apply to network infrastructure. If you are unsure whether your AI workloads are properly segmented, your CI/CD pipeline secrets are well-governed, or your incident response playbook covers supply-chain scenarios, reach out for a security assessment. At P J Networks, we can help you map your AI-related threat surface, review your dependency governance posture, and build a zero-trust pipeline security architecture — before the next supply-chain attack finds you. You can also explore more threat intelligence and analysis on the Sanjay Seth Insights blog.

The post LiteLLM 1.107.0 Supply Chain Breach: AI Credential Stealer Hit 2 Hours Before Removal — Is Your AI Stack Safe? appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

What Is Mark of the Web — and Why Does Breaking It Matter?

Mark of the Web (MotW) is a Windows security mechanism that automatically tags files downloaded from the internet with an alternate data stream attribute (Zone.Identifier). When you open a tagged file, Windows triggers a cascade of safety checks:

• SmartScreen inspects the file’s reputation and warns if it is unknown or malicious.
• Office Protected View opens documents in a sandboxed, read-only mode, blocking macro execution.
• Attachment Manager shows a security warning before executing downloaded scripts or executables.

This chain is one of the single most effective defenses against phishing and malicious-attachment campaigns in a default Windows deployment. Bypassing it silently removes all three layers at once. The attacker does not need code execution or a privilege escalation chain — just a victim who opens a file.

Technical Breakdown: CVE-2026-96951 in Detail

CVE-2026-96951 is a command injection vulnerability in the Windows Shell. When Windows Shell processes a specially crafted file — for example, a .zip archive, a .lnk shortcut, or another container format — it fails to correctly propagate the MotW attribute to the extracted or referenced content. As a result, files that originated from the internet are treated as locally-trusted, and none of the MotW-dependent safety checks fire.

The attack chain looks like this:

1. Attacker crafts a malicious archive or file container designed to exploit the Shell processing flaw.
2. The file is delivered via a phishing email, instant message, or a drive-by download link.
3. The victim opens the file. Because MotW is bypassed, no SmartScreen warning appears and Office documents open with macros enabled rather than in Protected View.
4. The malicious payload executes — commonly a loader that drops a remote access trojan (RAT), a ransomware encryptor, or an information stealer.

Microsoft has not publicly shared the precise file format exploited in the wild, but prior MotW bypasses (such as CVE-2023-36025 and CVE-2024-38213) were abused by ransomware operators — notably the Qakbot and DarkGate delivery ecosystems — within days of public disclosure. Security researchers expect the same playbook to apply here, meaning a rapid ransomware weaponization window is open right now.

The Broader Context: A Record-Breaking Patch Tuesday

CVE-2026-96951 is the most pressing fix in a historically large October 2026 Patch Tuesday. Microsoft addressed approximately 1,411 CVEs across Windows, Office, .NET, Azure, and its browser stack — the largest monthly release on record according to BleepingComputer. Of those, around 70–80 are rated Critical, the majority involving remote code execution.

Two additional zero-days were disclosed (but not confirmed exploited at the time of release):

• CVE-2026-108398 — A .NET Framework Security Feature Bypass. Technical details were already public before the patch, increasing the speed at which exploit code could appear. Organizations running .NET-dependent enterprise applications should treat this as a high-priority fix as well.
• A SharePoint-related zero-day whose details were publicly disclosed, though Microsoft has not confirmed active exploitation as of this writing.

Additionally, Windows 11 24H2 (Home and Pro) and Windows 10 Enterprise LTSB 2016 reached the end of their servicing lifecycle with the October 2026 update — they will receive no further security patches. Organisations still running these builds must upgrade immediately; they are now permanently unpatched against every future vulnerability, including CVE-2026-96951 variants.

For Indian enterprises managing distributed Windows fleets across branch offices — a common topology in manufacturing, BFSI, and retail — this creates compounding risk: endpoint fragmentation, delayed patch cycles, and now an actively exploited initial-access vector that bypasses your first line of phishing defence. I have written before about how an implant can persist silently inside your perimeter once initial access is achieved — the PEERSTITCH campaign on FortiGate devices is a prime example of what follows when attackers get their foothold undetected.

Why MotW Bypasses Are a Ransomware Favourite

MotW bypasses are disproportionately prized by ransomware operators because they solve the last-mile delivery problem. The most hardened perimeter — next-gen firewall, email gateway, DNS filtering — typically cannot inspect a password-protected archive or a file whose malicious behaviour only triggers after a user double-clicks it inside Windows. MotW is the last checkpoint before execution, and removing it silently is as good as having physical access to the endpoint.

The historical pattern is stark: every MotW bypass CVE since 2022 that was actively exploited was weaponised by a ransomware-as-a-service affiliate within two to four weeks of public disclosure. The disclosure for CVE-2026-96951 happened concurrently with patching — meaning the threat actor using it before October 13 may have already sold or shared the technique. The clock is running.

What You Should Do: Sanjay Seth’s Recommended Actions

After three decades managing enterprise security for Indian organisations — from FortiGate-protected campuses to distributed SD-WAN deployments — my recommendation is clear: treat this like a fire drill, not a routine patch cycle.

Immediate (within 24–48 hours)

• Deploy the October 2026 Cumulative Update to all Windows 10 and Windows 11 endpoints and Windows Servers immediately. WSUS, SCCM/Intune, and third-party patching tools all have this update available. Prioritise internet-facing workstations, executive devices, and any machine in your finance or HR team — the typical spear-phishing targets.
• Audit end-of-life Windows builds. Run a query in your endpoint management console for Windows 11 24H2 and Windows 10 LTSB 2016. These machines must be upgraded — there is no October 13 patch equivalent for a future MotW variant.
• Enable Enhanced Phishing Protection in Microsoft Defender SmartScreen (Windows Security > App & browser control). While CVE-2026-96951 bypasses the MotW tag itself, additional Defender telemetry can still flag known-malicious file hashes independent of the tag.

Short-Term (within the week)

• Review email gateway rules. Block or quarantine compressed archives (.zip, .7z, .rar, .iso, .img) sent from external senders unless explicitly whitelisted. Past MotW bypass exploits heavily used ISO and ZIP containers as the delivery vehicle.
• Audit your zero-trust segmentation on the endpoint side. A zero-trust architecture limits lateral movement even if a MotW-bypass payload does land and execute — contain the blast radius before it reaches your crown jewels.
• Brief your SOC team. Update detection rules to flag processes spawned from Shell host processes (explorer.exe, dllhost.exe) that immediately reach out to external IPs or write to %APPDATA% or %TEMP%. These are common post-MotW-bypass loader behaviours.

Strategic

• Accelerate the Windows 11 migration for any remaining Windows 10 standard support deployments. The end-of-life pressure is now acute, not theoretical.
• Evaluate Attack Surface Reduction (ASR) rules in Microsoft Defender for Endpoint. Rules such as “Block all Office applications from creating child processes” and “Block execution of potentially obfuscated scripts” provide defence-in-depth against MotW-bypass payload delivery.

Frequently Asked Questions

Does CVE-2026-96951 affect Windows Server as well as desktop Windows?

Yes. Microsoft’s advisory lists Windows Server 2016 through Windows Server 2025 as affected, in addition to Windows 10 and Windows 11. Server instances running as RDP jump-boxes or Citrix hosts are particularly exposed if users download files through browser sessions on those servers.

If my endpoints are behind a FortiGate IPS, am I protected without patching?

Partial protection at best. A FortiGate IPS signature may detect known exploit payloads delivered over HTTP/HTTPS, but cannot inspect encrypted channels or password-protected archives, and cannot prevent a user from opening a file that arrived via a personal email account or USB drive. IPS is a valuable layer, but patching is the only definitive mitigation. There is no workaround listed in Microsoft’s advisory.

Is there a public proof-of-concept (PoC) exploit available?

As of the October 13 disclosure, Microsoft has not shared technical details of the in-the-wild exploitation technique, and no weaponised public PoC was confirmed at that time. However, given that the vulnerability was being exploited before the patch, the technique is known to at least one threat actor. Security researchers typically reverse-engineer the patch diff within days, so a public PoC is a matter of when, not if.

What should I tell my board or senior leadership?

Frame it as a mandatory fire-safety update, not a discretionary IT task. An actively exploited zero-day with CISA’s emergency-equivalent three-day federal deadline means the threat is real, current, and confirmed. The cost of patching is measured in a managed maintenance window; the cost of not patching is a ransomware incident at the worst possible time. Authorise the emergency deployment now, and review your patch SLA policy afterward to ensure your organisation can respond within 72 hours for CISA KEV additions in future.

The Bigger Picture for Indian Enterprises

India’s large enterprises have increasingly complex Windows estates — often spanning headquarter campuses, regional offices, manufacturing floors, and remote workers on mixed-ownership devices. The National Cyber Security Policy and the RBI’s IT risk framework both call for timely patching of critical vulnerabilities. CVE-2026-96951 meets any reasonable definition of critical: it is a zero-day, actively exploited, rated 8.8 CVSS, and added to CISA’s emergency list. For SEBI-regulated entities and RBI-regulated banks, treating this patch as a compliance obligation rather than a best-effort recommendation is both prudent and likely mandatory under your existing cyber risk policies.

The NVD entry for CVE-2026-96951 and Microsoft’s Security Update Guide have the authoritative affected-version lists and KB article numbers for your specific Windows builds. For CISA’s full KEV listing, see cisa.gov/known-exploited-vulnerabilities-catalog. The BleepingComputer Patch Tuesday analysis is also an excellent reference for the full list of prioritised fixes in this month’s release. Additional context on the exploitation mechanics appeared in coverage by Dark Reading.

The post CVE-2026-96951 (CVSS 8.8): Windows Shell Zero-Day Bypasses SmartScreen — Patch Now Before Ransomware Actors Strike appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

India’s enterprise sector has expanded Wi-Fi and SD-Access deployments dramatically, and HPE Aruba is one of the dominant platforms in campus, healthcare, government, and BFSI networks. If you operate Aruba AOS-8 or AOS-10 — and tens of thousands of Indian organizations do — read this before the week is out.

The Bulletin: 72 Vulnerabilities, Eight Scored Perfect 10

HPE’s HPESBNW05162 advisory covers both ArubaOS generations simultaneously. AOS-10 is the cloud-native architecture running HPE Aruba Networking Central-managed gateways and access points; AOS-8 is the legacy-but-widely-deployed controller-based stack. Both are vulnerable. Both received fixes in the same drop.

The severity distribution is stark: of 72 CVEs, eight are rated CVSS 3.1 base score 10.0 — the highest possible score, indicating attacks require no privileges, no user interaction, and are network-reachable. Many of the remaining 64 flaws are rated High (7.x–9.x). This is not a routine quarterly patch cycle; this is a mass-severity event.

The eight CVSS 10.0 CVEs are:

Technical Breakdown: How Attackers Would Exploit These

The vulnerability classes here are well-understood — and that is exactly what makes them so dangerous in a public advisory without an embargo. Each attack path represents a foundational security failure:

Authentication Bypass (CVE-2026-79844, CVE-2026-79845, CVE-2026-79850): These flaws target PAPI — the Aruba Process Application Programming Interface — the internal management protocol used between ArubaOS components. An attacker who can reach the PAPI port (UDP 8211) can send crafted packets that the system accepts without any valid credentials, then chain into OS-level command execution. PAPI-based exploits have been weaponized before; BleepingComputer’s analysis of the bulletin confirms the same interface is in scope here.

Unauthenticated Command Injection (CVE-2026-79846): On AOS-8, this flaw allows a network-accessible, unauthenticated attacker to pass shell metacharacters into an underlying service, causing arbitrary commands to run as a privileged process. This is a textbook operating system takeover — if your AOS-8 management interface is reachable from a corporate LAN without proper segmentation, any employee or compromised endpoint becomes a potential threat actor.

SQL Injection to RCE (CVE-2026-79848, CVE-2026-79849): Two separate SQL injection paths exist in the AOS-8 codebase, both reachable without authentication. SQL injection escalating to RCE is possible when the underlying database driver or the application layer can be tricked into running OS-level commands — a pattern enabled by stacked queries or xp_cmdshell equivalents in embedded databases. Both flaws are rated 10.0, indicating HPE assessed the full RCE chain is achievable.

Buffer Overflows (CVE-2026-79847, CVE-2026-79851): On AOS-10, two unauthenticated buffer overflows exist in network-reachable services. Buffer overflows in embedded network OS code are highly reliable exploit targets: they can be used to overwrite control-flow data and redirect execution to attacker-controlled code, with no heap spray complexity in deterministic memory layouts. Without modern mitigations such as full ASLR/PIE and stack canaries — harder to guarantee on embedded firmware — these become trivially weaponizable after a single public PoC.

HPE’s advisory notes that some flaws require “preconditions outside of the attacker’s control” to be met, but crucially does not specify what those preconditions are. In practice, until those constraints are detailed, security teams should treat all eight flaws as unconditionally exploitable — that is the conservative, professionally defensible stance.

Am I Affected? Versions and Scope

The following builds are vulnerable:

• AOS-10: All 10.8.x builds up to and including 10.8.1.1; all 10.7.x up to 10.7.2.6; all 10.4.x up to 10.4.1.13
• AOS-8: All 8.13.x up to and including 8.13.3.0; all 8.10.x up to 8.10.0.23

Any hardware, virtual appliance, or cloud-managed instance running these builds is in scope — Mobility Conductors, Mobility Controllers, Mobility Gateways, and access points that inherit OS images from controllers. If you have a Aruba Central-managed fleet, check your assigned firmware baseline in Central before assuming cloud management equals automatic patching; Central does not auto-upgrade firmware without administrator action.

According to the advisory covered by Rescana’s detailed analysis, the fixed builds are:

• AOS-10.8.1.2 or later
• AOS-10.7.2.7 or later
• AOS-10.4.1.14 or later
• AOS-8.13.3.1 or later
• AOS-8.10.0.24 or later

Verify exact build numbers and download links directly in the official HPE security bulletin before upgrading.

What You Should Do Now — Sanjay Seth’s Defensive Playbook

Eight CVSS 10.0 vulnerabilities in network infrastructure deserve an emergency response posture, not a routine change ticket. Here is what I recommend to every client running HPE Aruba:

1. Immediate: Segment management interfaces. HPE’s workaround — and the most impactful single action you can take right now — is to ensure that all Aruba management interfaces (AOS-8 WebUI, CLI, PAPI) are accessible only from a dedicated, firewalled Out-of-Band Management (OOBM) network. No management interface should be reachable from a production VLAN, guest network, or the internet. If your architecture allows lateral reach to PAPI from any corporate VLAN, that is your immediate crisis.
2. Inventory all affected devices within 24 hours. Pull firmware versions from every Mobility Conductor, Controller, Gateway, and managed AP in your estate. Central’s firmware reporting dashboard and the CLI command show version will give you version strings. Cross-reference against the affected-version table above. Prioritise devices that are management-reachable from broader network segments.
3. Patch controllers and conductors before APs. In AOS-8 hierarchies, the Mobility Conductor orchestrates controller upgrades; patch the Conductor first, then push controller upgrades in batches. APs update automatically once the controller is on a fixed build. In AOS-10 / Central deployments, push the new firmware group baseline and deploy to device groups in staged rollouts to minimise outage windows.
4. Enable PAPI Security / Enhanced PAPI Security. For AOS-8 deployments not yet running Enhanced PAPI Security (shared secret-based authentication between controller and AP), enable it now — it is a documented Aruba feature and reduces the blast radius of PAPI-class exploits even on unpatched builds.
5. Enable audit logging and review for anomalies. Look for unexpected management logins, configuration changes, new administrator accounts, and unusual traffic to/from controller management IPs. If you have a SIEM, create alerts for ArubaOS syslog events around authentication failures and configuration changes for the next 30 days. The absence of known public exploits does not mean no one has reverse-engineered the patch.
6. Apply zero-trust principles to your wireless infrastructure. In my experience working with Indian enterprises on zero-trust campus architectures, network control-plane isolation is consistently the gap that converts a patched CVE into a lateral-movement incident. The management plane must be treated as a separate trust domain — segment it, authenticate every access, and log everything.

The India Context: Why This Matters for Domestic Enterprises

HPE Aruba is one of the three dominant wireless networking platforms in Indian enterprises, alongside Cisco and Fortinet. It holds particular market share in education, government, BFSI, and large campus deployments — sectors where Wi-Fi controller infrastructure is often refreshed on 5–7 year cycles, meaning many deployed systems run older but still-vendor-supported AOS-8 builds.

India’s CERT-In Vulnerability Note system has not yet issued a specific advisory on HPESBNW05162 as of this writing, but the mandatory 6-hour incident-reporting timeline under CERT-In’s 2022 directions means any exploitation of these flaws must be reported if it results in a breach. Given the volume and severity of the CVEs, I expect CERT-In will issue a formal note imminently.

Indian organisations with hybrid SD-WAN and campus networking deployments should note that a compromised Aruba gateway or controller sits at the intersection of user access, application traffic, and the SD-WAN overlay — making it one of the highest-value targets in the modern enterprise architecture.

Frequently Asked Questions

Are these vulnerabilities already being exploited in the wild?

As of HPE’s advisory publication on 22 October 2026, HPE stated it is not aware of any public exploit code or active exploitation targeting these CVEs. However, this window is typically short once a vendor advisory is public — security researchers and threat actors alike reverse-engineer patched binaries to reconstruct exploit paths. The absence of known exploitation today should not be interpreted as safety; it is a race condition, and patching is how you win it.

Does cloud-managed (Aruba Central) mean I’m automatically protected?

No. HPE Aruba Central is a management platform, not an auto-patching mechanism. While Central provides the console to push firmware updates, it does not push new firmware to devices automatically or without administrator action. You must review your firmware groups in Central, update the baseline to a fixed build, and deploy the update to each device group. Check your Central firmware compliance dashboard today.

What is the PAPI interface and why is it a recurring target?

PAPI (Process Application Programming Interface) is Aruba’s internal UDP-based communication protocol used between the controller and managed devices. It runs on UDP port 8211 and historically has been a target for authentication-bypass exploits because it is often reachable within the same LAN segment as managed devices. Multiple earlier CVEs in Aruba have involved PAPI. The recurring nature of PAPI-class vulnerabilities makes the Enable Enhanced PAPI Security configuration a mandatory baseline hardening step for any AOS-8 deployment, regardless of patch status.

What are the potential consequences of a successful exploit?

A successful exploit of any of the eight CVSS 10.0 CVEs gives an attacker full operating system control of the Aruba controller or gateway. From that position, an attacker can: intercept and decrypt all Wi-Fi traffic passing through the device; create rogue administrator accounts; modify routing and policy configurations; pivot into the management network; deploy persistent backdoors in the firmware; and disable security controls for other devices managed by the compromised controller. In a campus or enterprise context, a single compromised Mobility Conductor can cascade into control of every downstream controller and access point in the hierarchy.

For more context on how infrastructure vulnerabilities are chained in modern attacks, see SecurityWeek’s analysis of October 2026’s record-breaking Microsoft Patch Tuesday, which underscores how infrastructure-level flaws dominate today’s threat landscape.

Get a Security Assessment Before an Attacker Gets In First

If your organisation runs HPE Aruba networking — or any combination of campus, SD-WAN, and wireless infrastructure — the window between a public advisory and the first weaponised exploit is measured in days, not weeks. I offer rapid security assessments covering wireless and network infrastructure posture, management-plane segmentation gaps, and firmware lifecycle governance, tailored specifically for Indian enterprises.

Contact Sanjay Seth for a security consultation →

Whether you need an urgent vulnerability assessment, a zero-trust architecture review, or help building a credible patch management programme for your networking infrastructure, reach out today. The best time to assess your exposure is before an incident — the second-best time is right now.

The post 8 CVSS 10.0 Flaws in HPE Aruba AOS: 72 Vulnerabilities Patched — Act Before Exploits Drop appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

For Indian enterprises running distributed branch networks over VeloCloud — a common choice in BFSI, retail, and healthcare sectors — this is a direct threat to network sovereignty. Your SD-WAN control plane, the single pane of glass that governs every branch, every policy, every route, is the target.

What Is Arista VeloCloud Orchestrator, and Why Does It Matter?

VeloCloud, acquired by VMware and later incorporated into Arista’s SD-WAN portfolio, is one of the most widely deployed SD-WAN platforms globally. The VeloCloud Orchestrator (VCO) is the centralised management and policy plane: it configures edges (branch routers), controls application-aware routing, enforces security segmentation, and provides visibility across the entire wide-area network.

In enterprise deployments, VCO is the nerve centre. A compromise of VCO is not a single-branch problem — it is a full network compromise. An attacker with superuser operator access can modify routing policies, redirect traffic, disable security controls, access encrypted management tunnels, and position themselves for lateral movement into any connected branch or data centre segment.

For Indian enterprises that have deployed VeloCloud for their branch and retail networks — often the same networks carrying payment transactions, customer data, and operational technology — the blast radius of this vulnerability is severe.

Technical Breakdown: CVE-2026-114625

CVE-2026-114625 is a SQL injection vulnerability (CWE-89) in the on-premises VeloCloud Orchestrator web application. Its severity scores — CVSS 3.1: 9.9, CVSS 4.0: 9.4 — reflect how easily it can be reached and how damaging exploitation is.

The critical design flaw is in the access requirement. Arista’s advisory confirms that any authenticated VCO portal user, including an account with the lowest built-in tenant role (Enterprise Read Only), can trigger the vulnerability. In most enterprise VCO deployments, read-only accounts are distributed liberally — to NOC engineers, junior analysts, vendor support teams, and third-party consultants. Every one of those accounts is now a potential attack vector.

Upon successful exploitation, the attacker is able to masquerade as a local superuser operator, bypassing all tenant isolation and gaining access to internal-only management functions. From that position, the attacker can:

• Read, modify, or delete SD-WAN policies across all tenants and edges
• Access credentials and cryptographic material stored in the orchestrator
• Pivot to connected branch networks via the management plane
• Establish persistence through backdoored configurations or new admin accounts

Arista states the product is exposed by design in its default configuration, and no configuration change alone is sufficient to prevent exploitation — only patching or strict network-layer isolation of the VCO web interface mitigates the risk.

A Disturbing Pattern: Three VeloCloud Zero-Days in One Year

CVE-2026-114625 is not an isolated event — it is the culmination of an alarming pattern of exploitation targeting VeloCloud Orchestrator in 2026:

• July 2026 — CVE-2026-16812 (CVSS 10.0): An unauthenticated OS command injection in on-premises VCO. Maximum severity. Arista discovered the vulnerability through external reporting and confirmed active exploitation immediately. CISA added it to the KEV catalog on July 27, 2026, with federal agencies given three days to remediate.
• September 2026 — CVE-2026-93952: A second VCO zero-day, involving improper input validation and active exploitation targeting certificate-based authentication pathways in on-premises deployments.
• October 22, 2026 — CVE-2026-114625 (CVSS 9.9): The SQL injection zero-day. Active exploitation confirmed at the time of disclosure.

Three actively-exploited zero-days in one product in under four months is a red flag that warrants a strategic reassessment — not just a patch. Threat actors have clearly identified VeloCloud Orchestrator as a high-value target. The reasons are obvious: compromise one VCO instance and you own the SD-WAN of every branch it manages.

SecurityWeek’s reporting on this pattern reinforces what security architects have been warning for years: management planes for network infrastructure are crown jewels, and their attack surface has been systematically underestimated.

Active Exploitation: What We Know

Arista’s disclosure confirms active exploitation at the time of publication. Two attacker-controlled IP addresses have been identified in exploitation attempts: 74.82.197[.]86 and 38.54.50[.]151. Block these at your perimeter immediately and search your VCO access logs retroactively.

Critically, Arista’s advisory does not specify what attackers did after gaining access. The post-exploitation footprint is unknown publicly. That ambiguity is itself a threat intelligence gap — organisations that have already been compromised may not know it yet. Arista also does not confirm whether patching removes access an attacker has already established, which means patching alone may not be sufficient for potentially compromised environments.

The three-zero-day pattern, combined with the relatively low entry bar (any authenticated account), suggests a sophisticated, persistent threat actor — or multiple groups — who have made SD-WAN management infrastructure a priority target in 2026. This aligns with broader intelligence reports documenting nation-state and financially motivated actors targeting network infrastructure control planes as a precursor to large-scale espionage or ransomware campaigns.

India-specific context: BleepingComputer’s coverage notes that cloud-hosted and dedicated orchestrators were patched by Arista directly. However, India has a large installed base of on-premises VCO deployments driven by data localisation requirements and private cloud preferences. These on-premises instances are the ones at risk and must be patched by the customer.

What You Should Do Right Now

Here is the prioritised response sequence for VeloCloud Orchestrator operators, drawn from Arista’s advisory and sound incident response practice:

1. Identify your VCO version immediately. Log into your orchestrator and check the software version. If you are running VCO 5.2.x before 5.2.3.18, VCO 6.1.x before 6.1.3.10, or VCO 6.4.x before 6.4.2.12, you are vulnerable. Versions on the 7.0 train are not listed as affected.

2. Patch without delay. Update to 5.2.3.18, 6.1.3.10, or 6.4.2.12 depending on your release track. Consult Arista’s release notes and your support contract for the upgrade path. If you have a maintenance window constraint, implement network isolation controls immediately (see step 4) while you schedule the patch.

3. Audit user accounts — especially read-only accounts. Enumerate every account with VCO portal access, including vendor accounts, NOC observers, and consultant logins. Temporarily revoke or suspend accounts that are not immediately necessary. Rotate credentials for all remaining accounts after patching.

4. Restrict VCO web access at the network layer. The VCO management interface should only be reachable from dedicated admin workstations and jump hosts on an out-of-band management network. If it is currently reachable from general corporate or production subnets, fix that immediately — this is a zero-trust network segmentation failure that applies regardless of this CVE.

5. Block the known attacker IPs at your perimeter. Add 74.82.197[.]86 and 38.54.50[.]151 to your firewall and WAF blocklists immediately. Conduct a retroactive log review for any connections from these addresses to your VCO.

6. Review VCO audit logs for anomalies. Look for unexpected configuration changes, new admin account creation, policy modifications, or edge device reconfigurations — especially between July and October 2026. The three-CVE exploitation window means your orchestrator may have been probed or compromised before this latest disclosure.

7. Treat your environment as potentially compromised until proven otherwise. If you find suspicious activity, engage your incident response team and consider a full orchestrator rebuild from a known-clean backup rather than patching in place.

From a SD-WAN architecture perspective, this incident also reinforces a design principle that is too often deprioritised: the management plane must be architecturally isolated from the data plane and from the corporate network. If your VCO is accessible from any workstation with an internet connection, you are not running a secure SD-WAN — you are running a flat network with SD-WAN features bolted on.

FAQ

Are cloud-hosted VeloCloud Orchestrator instances affected by CVE-2026-114625?

No. Arista has already patched cloud-hosted and dedicated VCO instances. Only on-premises VCO deployments running versions before 5.2.3.18, 6.1.3.10, or 6.4.2.12 are affected. If you are unsure whether your deployment is on-prem or cloud-hosted, contact your Arista account team or check your service agreement.

Does this CVE affect VeloCloud Edges or Gateways at branch sites?

No. The vulnerability is specifically in the VeloCloud Orchestrator web application. VeloCloud Edge appliances at branch sites and VeloCloud Gateways in carrier networks are not affected. That said, if an attacker gains superuser operator access to VCO, they can potentially reconfigure edges and gateways — making VCO compromise indirectly devastating for the entire SD-WAN fabric.

Is a read-only account genuinely enough to exploit this?

Yes, according to Arista’s own advisory. The Enterprise Read Only role — the lowest built-in tenant role in VCO — is sufficient to trigger the SQL injection and escalate to superuser operator access. This dramatically expands the attack surface, since read-only accounts are routinely shared with NOC engineers, junior staff, external auditors, and vendor support teams.

If I can’t patch immediately, what is the best interim control?

Strictly limit network access to the VCO web interface. Place VCO behind a jump host or VPN that requires multi-factor authentication, and restrict access to a small, named group of administrators. Revoke or suspend all vendor and third-party accounts until after patching. Additionally, block the two known attacker IPs at your perimeter firewall and enable enhanced logging on the VCO interface. These are stopgap measures — patching remains the only true fix.

The bottom line: CVE-2026-114625 is a near-maximum-severity, actively-exploited zero-day in the management plane of one of the world’s most widely deployed SD-WAN platforms. Three such flaws in four months is not bad luck — it is a targeted campaign. If you run on-premises VeloCloud Orchestrator, patch today, not this week.

Arista’s security advisory and detailed technical guidance are available via the Arista Security Advisories page (SA 0199). Additional context is available from SecurityOnline, SecurityWeek, and the CISA KEV catalog.

The post CVE-2026-114625 (CVSS 9.9): Arista VeloCloud Orchestrator Zero-Day Exploited — Third SD-WAN Attack in 2026 appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

What Is CVE-2026-0257?

CVE-2026-0257 is an authentication bypass vulnerability in the GlobalProtect portal and gateway components of Palo Alto Networks PAN-OS. The root cause is subtle but devastating: vulnerable builds accept any authentication override cookie they can decrypt, without verifying that the appliance itself actually issued that cookie. An attacker who can create or obtain a validly-formatted cookie — whether through a second compromised device in the same certificate trust chain, a leaked or reused certificate, or a brute-force approach against weak HMAC keys — can present it as proof of a legitimate authenticated VPN session.

Palo Alto initially scored the flaw at CVSS 4.7 (Medium) when patches were released in May 2026. On 29 May 2026, Rapid7 published a technical analysis and working proof-of-concept exploit; within 48 hours Palo Alto revised the official CVSS score upward to 7.8 (High). Singapore’s Cyber Security Agency assessed the same flaw at CVSS v3.1 9.1 — a reminder that CVSS arithmetic can diverge significantly depending on assumed environmental factors. CISA added CVE-2026-0257 to its Known Exploited Vulnerabilities catalog with a federal remediation deadline of 1 June 2026. With three active ransomware crews now exploiting it and an ESXi pivot technique confirmed, the risk is far higher than the vendor headline score suggests.

Technical Breakdown: How the Bypass Works

GlobalProtect’s authentication override feature lets an authenticated user obtain a cookie from one gateway and present it at another, avoiding repeated MFA challenges across multiple sites. The feature is not enabled by default — an administrator must explicitly turn it on. However, many large enterprises and distributed organisations activate it for usability, especially in SD-WAN or multi-site deployments common across Indian enterprise campuses.

The bypass exploits three conditions that must all be true simultaneously:

1. GlobalProtect portal or gateway is configured and internet-facing
2. Authentication override cookies are enabled
3. The certificate used to sign override cookies is either reused across multiple appliances or is otherwise accessible to the attacker (e.g., leaked private key, certificate shared with a compromised third-party gateway)

When these conditions align, an attacker forges or replays a valid override cookie, bypasses the login prompt entirely, and establishes a full VPN tunnel — appearing to PAN-OS logs as a legitimate user session. No username or password is required. Once inside, the attacker has Layer-3 access to whatever the VPN segment can reach, which in typical enterprise architectures includes internal file shares, Active Directory, backup servers, and virtualisation management planes.

According to Unit 42’s updated threat brief (20 October 2026), Palo Alto also provides a temporary CLI workaround — a command that disables strict HMAC validation on override cookies — intended only for phased upgrades where not all gateways can be patched simultaneously. Organisations that have left this workaround in place permanently have effectively disabled the only protection against cookie forgery.

Three Ransomware Gangs — and a Dangerous ESXi Pivot

Unit 42 attributes active exploitation to two ransomware operators it tracks under its Scorpius naming convention. ReliaQuest and The Hacker News have additionally documented a third group deploying Settra ransomware via the same entry point.

The most alarming aspect of the October 20 update is the ESXi pivot technique. In at least one confirmed intrusion, after gaining VPN access through CVE-2026-0257, attackers pivoted laterally to vCenter — the management plane for the organisation’s entire virtualised infrastructure. They then:

1. Disabled the execInstalledOnly security control on ESXi hosts (which normally prevents execution of arbitrary binaries)
2. Mounted the virtual disk (VMDK) of a domain controller from outside the guest OS, bypassing endpoint detection entirely
3. Extracted Active Directory credentials, password hashes, and Kerberos tickets offline — no alerting SIEM rule for “unusual logon” fires because there was no logon inside the guest

This technique effectively turns a medium-severity VPN bypass into a full domain compromise, all without generating the in-guest behavioural signals that most EDR and SIEM tools are tuned to catch. The lesson: patching the VPN is necessary but not sufficient — any organisation that was exposed before patching must conduct a full threat hunt across its virtualisation layer and AD environment.

What You Should Do — Sanjay Seth’s Practical Guidance

After 30 years of defending enterprise networks across India and the region, including multi-site zero-trust deployments with both Fortinet and Palo Alto stacks, my recommendation is structured around three horizons:

Immediate (Within 24 Hours)

• Verify your exposure: Check whether GlobalProtect portal/gateway is configured, authentication override cookies are enabled, and your certificate is shared across multiple appliances
• Patch now — see verified fixed builds from Palo Alto Networks’ security advisory:
  • PAN-OS 12.1: 12.1.4-h6 or 12.1.7+
  • PAN-OS 11.2: 11.2.4-h17, 11.2.7-h14, or later hotfixes
  • PAN-OS 11.1: 11.1.4-h33 or later
  • PAN-OS 10.2: 10.2.7-h34 or later
  • Prisma Access 11.2: 11.2.7-h13 or later
• Terminate all active VPN sessions after patching — a forged session active at patch time remains valid until terminated
• Rotate the certificate used to sign authentication override cookies, then re-enable strict HMAC validation if you previously used the CLI workaround

Short Term (Within 7 Days)

• Hunt for the ESXi pivot: Review vCenter access logs for connections from unexpected IP ranges, especially during off-hours. Look for changes to execInstalledOnly and for any VMDK file access from hosts that are not the running guest
• Audit AD for compromise: Run a KRBTGT password reset (or dual-reset) and review privileged account usage since the patch window opened in May 2026. If you cannot rule out prior exploitation, assume your domain has been compromised and act accordingly
• Review your PAN-OS management interface exposure — while CVE-2026-0257 targets the GlobalProtect plane, our recent coverage of CVE-2026-0322 showed that management interfaces of the same appliances are also under active attack. Ensure management access is restricted to out-of-band networks or a dedicated management VLAN with strict ACLs

Strategic (Zero-Trust Posture)

• Do not trust VPN authentication alone as an access-granting event. Implement continuous identity verification and device posture checks post-authentication — the zero-trust principle of “never trust, always verify” is precisely designed for the scenario where the VPN perimeter has been bypassed
• Segment your virtualisation management plane from the network segments reachable by VPN users. In a properly segmented architecture, a compromised VPN session should not have direct Layer-3 access to vCenter or ESXi management interfaces
• Instrument VMDK access: Alert on any process reading raw VMDK files on hosts where the guest OS is live — this is almost never legitimate and is a strong indicator of credential-harvesting activity

Frequently Asked Questions

Is my organisation at risk if we disabled authentication override cookies?

If GlobalProtect authentication override cookies were never enabled, you are not vulnerable to CVE-2026-0257. However, you should still patch to a fixed PAN-OS build, as the advisory covers related hardening. Verify the cookie feature state in your GlobalProtect portal and gateway configuration tabs, not just through memory — misconfigurations in templated deployments are common.

Can the ESXi pivot happen even if we patched in May?

Patching on 1 June (the CISA deadline) means your window of exposure was potentially several weeks. If CVE-2026-0257 was exploitable in your environment during that window, an attacker may have established persistence that survives the patch. The vCenter pivot and offline VMDK credential theft happen after initial access — meaning any undetected sessions from May or June could have led to long-dwell-time compromise that the October patch does not remediate. Threat hunting is mandatory.

Which PAN-OS versions are safe?

Per the official Palo Alto advisory, fixed releases exist across PAN-OS 10.2, 11.1, 11.2, and 12.1. PAN-OS 10.1 and earlier are end-of-life and do not have patches — if you are running end-of-life code, upgrade to a supported branch immediately. Panorama and Cloud NGFW are not affected by this specific CVE.

Does Fortinet equipment face the same risk?

CVE-2026-0257 is specific to Palo Alto Networks PAN-OS GlobalProtect. Fortinet VPN products have their own CVE history — FortiGate SSL-VPN vulnerabilities have been extensively covered on this blog, including the recent PEERSTITCH implant and Gentlemen ransomware campaigns. The technique of abusing authentication override or session-resumption features is a pattern worth examining in any vendor’s VPN implementation. If your FortiGate SSL-VPN is unpatched, treat it with the same urgency.

The Bigger Picture for Indian Enterprises

India’s enterprise sector has invested heavily in Palo Alto Networks’ GlobalProtect for hybrid workforce connectivity — from banking and financial services to IT outsourcing firms and critical infrastructure operators. With CERT-In’s 6-hour mandatory incident reporting requirement now firmly in force, a ransomware deployment that originates from an unpatched VPN gateway carries not just operational risk but regulatory and reputational consequences. The three-gang exploitation of CVE-2026-0257, combined with the ESXi pivot technique, means a single unpatched appliance could trigger a full-organisation crisis requiring mandatory disclosure.

This is also a pointed reminder that perimeter-based security — where “inside the VPN” equals “trusted” — is an outdated model. The VPN bypass leads directly to the credential store. Zero-trust network access (ZTNA), continuous device posture validation, and microsegmentation of the virtualisation plane are no longer aspirational architectures; they are now the minimum bar for enterprise resilience.

Is your GlobalProtect deployment patched and threat-hunted? If you are not certain — or if your organisation has been running a vulnerable PAN-OS build since May — contact Sanjay Seth for a rapid security assessment. With 30 years of hands-on network security experience across FortiGate, Palo Alto, and zero-trust deployments, P J Networks can help you determine whether your environment was exposed and what immediate remediation steps are required before the next ransomware group comes knocking.

The post CVE-2026-0257 (CVSS 7.8): Qilin, INC & Settra Ransomware Exploit PAN-OS GlobalProtect — Attackers Now Pivot to ESXi appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

GitLab’s October Déjà Vu: Two CVSS 10 Flaws in Ten Days

Ten days ago, Sanjay Seth’s team covered CVE-2026-97229 — a CVSS 10.0 integer overflow in GitLab’s CI/CD Regular Expression Compiler that carried a public exploit and was actively targeted in the wild. Patched versions at the time were 19.2.8, 19.3.5 and 19.4.2. Organizations scrambled to update, and most did.

Now comes CVE-2026-110264, and its scope dwarfs the first. Where CVE-2026-97229 was discovered in the CI/CD pipeline component and affected recent releases, CVE-2026-110264 lives in the Onigmo regex library that GitLab’s own bundled Ruby has shipped with since version 7.0 — more than a decade of packaged builds. GitLab discovered the flaw while investigating the October 12 patches, found a deeper root in the Ruby runtime, and pushed fixes for every maintained branch plus the legacy 18.x series on 21 October.

The researcher who found and responsibly disclosed it through HackerOne is credited only by the handle joaxcar. GitLab has not published a detailed root-cause write-up yet, but the advisory confirms: no authentication is required, no privileges are needed, and no user interaction takes place on the victim’s side. That maps to a CVSS 10.0 with all base metrics at maximum severity.

Technical Breakdown: How a Regex Integer Overflow Becomes Unauthenticated RCE

GitLab’s Omnibus packages and Container-Native GitLab (CNG) images ship with their own bundled Ruby runtime, distinct from any Ruby installed on the underlying operating system. That bundled Ruby includes Onigmo, a high-performance regular expression engine forked from Oniguruma and embedded since GitLab 7.0.

The vulnerability is an integer overflow in Onigmo’s regex compiler. When a regex pattern causes the compiler’s internal length counter to overflow, it writes beyond its allocated buffer. On an affected version, an attacker can submit a crafted pattern through any endpoint that triggers regex compilation — and because regex evaluation happens before authentication in several code paths, the attacker needs no account, no session token, and no privileged access.

The exploit primitive — a heap corruption from an integer overflow — is the same class of memory corruption that underlies some of the most powerful offensive tooling seen in enterprise environments. While GitLab has not published a proof-of-concept timeline, independent researchers have noted that this attack surface is public-facing, parser-based, and requires no user interaction, a combination historically associated with rapid weaponisation once details circulate in underground forums.

Why the October 12 Patch Leaves You Exposed

This is the most dangerous misunderstanding right now. Organizations that read the original CVE-2026-97229 advisory and applied the October 12 builds — 19.2.8, 19.3.5 or 19.4.2 — addressed only the CI/CD pipeline overflow. They did not receive the Onigmo fix, because that fix was not ready until October 21.

The October 21 builds sit one version increment above the October 12 builds in every branch:

• Branch 19.2: 19.2.8 (Oct 12) → 19.2.9 (Oct 21) ← upgrade to this
• Branch 19.3: 19.3.5 (Oct 12) → 19.3.6 (Oct 21) ← upgrade to this
• Branch 19.4: 19.4.2 (Oct 12) → 19.4.3 (Oct 21) ← upgrade to this
• Branch 19.5: 19.5.1 (Oct 21)
• Branch 19.1: 19.1.9 (Oct 21)
• Branch 19.0: 19.0.10 (Oct 21)
• Branch 18.11: 18.11.13 (Oct 21)

If your self-managed instance is running anything not on that list, it is vulnerable. If it is internet-facing — as many corporate GitLab deployments are, for remote developer access — you should treat this as a priority-zero patch.

India Context: Why Self-Managed GitLab Is Everywhere — and at Risk

GitLab is particularly prevalent in India’s technology landscape. Large IT service providers, product engineering teams, public-sector defence contractors, and fintech organisations routinely operate self-managed GitLab because it keeps their source code on-premise, behind the corporate perimeter. That deployment choice was sound from a data-residency and compliance standpoint. However, it also means that every one of those instances is now carrying a CVSS 10.0 RCE until upgraded.

Worse, many Indian organisations with multi-site deployments run GitLab behind an SSL-terminating reverse proxy with a WAF. A WAF rule for this flaw does not yet exist in any major product’s default ruleset, because the attack path is through legitimate GitLab functionality — regex compilation — not through a known-malicious payload pattern. WAF is not your safety net here.

For organisations regulated under India’s DPDP Act or those holding RBI mandates, an unauthenticated RCE on the source code repository is also a potential data breach event the moment it is exploited. Your DevSecOps pipeline, your signing keys, your credentials stored in CI/CD variables, your entire source code history — all reachable once an attacker has code execution on the GitLab server.

What You Should Do Right Now

As a zero-trust practitioner and long-time GitLab deployment consultant across Delhi NCR and multi-branch Indian enterprises, here is the prioritised action list:

1. Check your running version immediately. Log in to the Admin Area → Help. If you see any build older than the patched versions listed above, stop reading and open a change request now.
2. Plan for downtime on branches 19.3 and 19.4. Those branches introduce database migrations in 19.3.6 and 19.4.3. GitLab will be unavailable during the migration. Block developer access before starting the upgrade to prevent failed operations from corrupting data mid-migration.
3. Restrict network access immediately if you cannot patch tonight. If internet-facing, restrict the GitLab web port (443) to known IP ranges using your firewall or security group until the patch can be applied. This is a compensating control, not a fix.
4. Rotate all CI/CD secret variables. Even if you have no evidence of exploitation, treat your GitLab CI/CD variables as potentially compromised if your instance was internet-exposed and unpatched after 21 October. Rotate tokens, API keys, and deployment credentials stored there.
5. Review Gitaly and GitLab Runner service accounts. A successful exploit gives the attacker the privilege level of the GitLab application process. Map what that account can reach — internal APIs, database credentials, Gitaly storage — and limit those paths.
6. Check your GitLab production.log and gitlab-rails/api_json.log for unusual patterns: very long search, filter, or query parameters containing regex metacharacters, HTTP 500 responses accompanied by crashes in sidekiq.log, or unexpected high CPU on the Puma workers. These are early indicators of exploit attempts.
7. Implement zero-trust network access (ZTNA) for your GitLab instance. Putting self-managed GitLab behind a device-identity and user-identity aware zero-trust gateway means that even a CVSS 10.0 public-facing flaw is only reachable to authenticated, posture-checked sessions — dramatically reducing the exploitable attack surface before a patch is even available.

The Bigger Picture: GitLab as Critical Supply-Chain Infrastructure

Two CVSS 10.0 vulnerabilities in GitLab within a ten-day window signals something important: the platform is under intensive security scrutiny, and the Onigmo library — shared across many open-source projects that bundle Ruby — is an attractive research target. The same Onigmo engine is used in other Ruby-based products; expect related advisories to follow.

More broadly, source code repositories have become Tier-1 targets for state-linked actors and financially motivated ransomware groups. The China-linked ARMORY CASTLE group’s exploitation of BeyondTrust Remote Support earlier this month shows how attackers chain perimeter vulnerabilities to reach deep into enterprise infrastructure. A GitLab compromise, by contrast, gives an adversary the keys to the codebase itself — a supply-chain foothold that can persist for months before discovery.

The good news: as of 22 October, there is no confirmed exploitation and no public proof-of-concept. You still have a head start. Use it.

Frequently Asked Questions

Does this affect GitLab.com or GitLab Dedicated cloud instances?

No. GitLab patched its own SaaS environment proactively before publishing the advisory. If you use GitLab Dedicated, instances running the internal builds 19.3.5-internal0 or 19.4.2-internal0 and later are also already covered. Only self-managed installations are at risk — meaning any GitLab you installed and operate yourself, on-premise or in your own cloud tenant.

I applied the October 12 patch for CVE-2026-97229. Am I safe?

No. The October 12 patches (19.2.8, 19.3.5, 19.4.2) fixed the CI/CD integer overflow (CVE-2026-97229) but did not include the Onigmo fix. CVE-2026-110264 requires a separate upgrade to the October 21 builds listed in this article. Think of it as two different mechanics under the same bonnet — fixing one does not fix the other.

Is there any WAF or IPS rule that can block exploitation until we patch?

Not reliably. The attack flows through legitimate GitLab functionality (regex compilation), and the malicious payload is a crafted regex string that differs only subtly from valid patterns. No major WAF vendor has published a signature as of 22 October. A network-level block of inbound GitLab access to known-good IPs is a reasonable compensating control, but it is not a substitute for patching. GitLab has explicitly stated: there is no workaround.

What is the risk if I’m running GitLab only on an internal LAN with no internet exposure?

Significantly lower, but not zero. An attacker who has already breached your perimeter — through phishing, a compromised laptop, or a separate vulnerability — can pivot to GitLab from inside the LAN. Given that GitLab is typically one of the most privileged internal services (it holds your source code, CI/CD secrets, and often service account credentials), it remains a high-value target even in a non-internet-facing deployment. Patch it anyway — ideally within 72 hours.

Get Expert Help Securing Your GitLab Deployment

Managing patch windows, rotating CI/CD credentials, and designing zero-trust access for developer tools takes practised hands. Sanjay Seth and the P J Networks team have deployed and hardened GitLab for some of India’s most demanding engineering organisations. If you need an emergency assessment of your current GitLab exposure, help designing ZTNA controls, or a full DevSecOps security review, reach out for a consultation. We respond within hours for active security incidents.

Sources: GitLab Critical Security Release Advisory · The Hacker News · GB Hackers · SOC Prime Analysis · Rescana Advisory · Safeguard.sh

The post CVE-2026-110264 (CVSS 10.0): GitLab’s Second Critical RCE in 10 Days Hits Every Version Since 2014 — Patch Now appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

What Is PHP2Shell and Why Does It Matter Right Now?

PHP2Shell is the collective name for two linked memory-corruption vulnerabilities in the PHP core interpreter itself, not in any application framework, plugin, or CMS layered on top of it. They were disclosed and patched simultaneously on 21 October 2026 following responsible disclosure by researchers at Wiz Research, Calif, and OpenAI’s Codex Security team.

Unlike typical application-layer bugs that target a misconfigured WordPress plugin or an insecure custom API endpoint, PHP2Shell lives inside the language runtime. That means every PHP application is potentially vulnerable, regardless of how securely its application code was written. A hardened, thoroughly pen-tested Laravel application running on an unpatched PHP version is just as exposed as an abandoned legacy system. The risk is the runtime, not the app.

For Indian enterprise IT teams, the exposure is especially acute. Hundreds of thousands of web-facing services across banking, insurance, e-commerce, logistics, and government are built on PHP-based platforms — Magento, Moodle, SugarCRM, custom Laravel portals, WordPress microsites, legacy Joomla installations. Many of these run on PHP versions that are already end-of-life, making this patch cycle both urgent and complex.

Technical Breakdown: Two Bugs, One Devastating Chain

The two CVEs exploit different PHP subsystems but share a common root cause: PHP trusting a pointer to memory it has already freed, then using that pointer as valid, live data. The technical term is use-after-free (UAF) — one of the most dangerous memory-safety bug classes, capable of producing memory disclosure, control-flow hijack, and ultimately arbitrary code execution.

What makes PHP2Shell particularly dangerous in practice is that exploitation requires no authentication, no valid session, and no special server configuration beyond PHP being network-reachable. On a default PHP-FPM deployment with persistent worker processes — the most common production configuration globally — a single malformed upload request can corrupt a worker’s memory state such that the very next legitimate request on that same worker triggers the use-after-free and code execution payload.

The involvement of AI is equally significant. Wiz Research used OpenAI’s Codex Security tooling alongside manual analysis to trace these complex, multi-step use-after-free chains across PHP’s large and complex C codebase — one of the most significant real-world demonstrations of AI-assisted vulnerability research discovering infrastructure-level security flaws. The implication for defenders: if defensive AI can find these bugs, well-resourced threat actors using the same tools will too, and faster than vulnerability databases can track them.

Affected Versions and Patch Status

PHP’s own advisory covers its four supported release branches. However, researcher analysis indicates the underlying weakness extends as far back as PHP 5.4, meaning end-of-life installations are exposed without any upstream fix available:

• PHP 8.5.12 — patched (released 21 Oct 2026)
• PHP 8.4.27 — patched
• PHP 8.3.36 — patched
• PHP 8.2.35 — patched
• PHP 8.1 and older — no upstream patch from PHP project; request a security backport from your Linux distribution (Red Hat, Ubuntu/Debian, SUSE) or managed-hosting vendor (Plesk, cPanel, Hetzner, DigitalOcean)
• PHP 7.x and 5.x — end-of-life; no fix coming; immediate migration or compensating controls are your only options

The authoritative GitHub Security Advisories are GHSA-w8hw-w9fx-j79w for CVE-2026-109618 and GHSA-6wmf-4rv5-p3rp for CVE-2026-109619. The full technical advisory from the PHP team is available at php.net/security.

Exploitation Activity: The Race Against Mass Compromise

Within hours of the emergency patches shipping on 21 October 2026, threat-intelligence firm watchTowr confirmed it was observing active exploitation attempts targeting both CVE-2026-109618 and CVE-2026-109619 in the wild. As of 14:19 UTC on 21 October 2026, no confirmed successful intrusions leveraging these specific flaws had been publicly detailed — but attack code is already circulating, and historical patterns are clear: the gap between “proof-of-concept circulates” and “mass exploitation begins” is typically measured in days, sometimes hours.

BleepingComputer and SecurityWeek both warn that mass exploitation is likely imminent given how widely PHP is deployed and how straightforward the attack path is once a working exploit is available. Indian organisations running public-facing PHP applications — particularly those still on PHP 7.x, 8.0, or 8.1 — should treat this as a P0 incident.

This pattern of critical RCE vulnerabilities in foundational web platform components is unfortunately familiar. Earlier this year, we documented the WordPress core RCE zero-day (CVE-2026-87902) that similarly exploited PHP’s attack surface to compromise millions of sites. The convergence of these PHP-ecosystem vulnerabilities represents a sustained, structural risk to any organisation with a web presence — not a one-off event to patch and forget.

What You Should Do: Expert Guidance for the Next 72 Hours

As a cybersecurity practitioner with over three decades of hands-on experience securing enterprise networks across India’s banking, manufacturing, and government sectors, here is my prioritised action plan:

Immediate Actions (Next 4 Hours)

1. Inventory PHP versions across your entire estate. This includes web servers, application servers, shared hosting panels, CI/CD build agents, development and staging environments, and internal tooling. Run php -v on each host, or use your SIEM to query for active PHP-FPM processes and their versions. If you have a CMDB, pull all records with PHP as a component — assume it is incomplete and validate.
2. Patch all PHP 8.2+ instances immediately. On Debian/Ubuntu: apt update && apt upgrade php8.x. On RHEL/Rocky: dnf update php. On Windows: download from windows.php.net. Crucially: restart PHP-FPM workers after upgrading — the patch does not take effect in running worker processes.
3. Place public-facing PHP endpoints behind your WAF with updated signatures. FortiGate with FortiGuard IPS, or any modern WAF, should be updated with PHP2Shell detection rules. FortiGuard Labs typically releases coverage within 24–48 hours for critical disclosures of this severity; check Security Profiles → IPS → Update Now on your FortiGate now.

Short-Term Actions (Next 72 Hours)

1. Apply compensating controls for PHP 8.1 and older systems that cannot be patched immediately. In php.ini, set a fixed memory_limit (never -1, which removes the limit that triggers CVE-2026-109618). Enforce upload size limits at the nginx or Apache reverse-proxy layer. Restart PHP-FPM after every configuration change — changes to php.ini do not apply to running workers.
2. Hunt for compromise indicators. Review PHP error logs for unusual OOM (out-of-memory) events, anomalous PHPSESSID cookie sizes in access logs, unexpected PHP-FPM worker crashes, or signs of webshell activity (base64-encoded eval() calls, unexpected outbound connections from PHP processes). watchTowr’s advisory and Datadog Security Labs’ live blog provide indicators of compromise to check against.
3. Prioritise PHP 8.1 and older instances for emergency migration. Engage your distribution vendor for a backport. If no backport is available and migration is impossible within days, consider taking the application offline until a fix is in place — the risk of serving a PHP RCE vector to the internet is greater than most downtime impacts.

Strategic Actions (Next 30 Days)

1. Enforce a PHP version policy in your software procurement and vendor contracts: no new deployments on end-of-life PHP branches, automatic upgrade obligations within 30 days of a critical CVE disclosure.
2. Implement network-level zero-trust segmentation so that PHP application servers cannot initiate arbitrary outbound connections — limiting lateral movement options for an attacker who achieves RCE. See our practical FortiGate zero-trust architecture guide for a production-validated implementation approach.
3. Evaluate Runtime Application Self-Protection (RASP) for your most critical PHP workloads as a defence-in-depth layer against future zero-days in the PHP runtime itself — a category of vulnerability PHP2Shell proves is not hypothetical.

Frequently Asked Questions

Does PHP2Shell only affect Linux servers?

No. The use-after-free conditions are in PHP’s core interpreter and are fundamentally platform-agnostic — PHP runs on Linux, Windows, and macOS, and all are affected in principle. Memory allocation behaviour and worker process models differ between platforms, which may affect how reliably exploitation works in practice, but no platform should be assumed immune. All systems running affected PHP versions should be patched, regardless of operating system.

If I am behind a CDN or WAF, am I protected from PHP2Shell?

A WAF or CDN with current signatures provides a meaningful compensating control but is not a substitute for patching. PHP2Shell exploits conditions deep in the PHP interpreter’s memory management; a sufficiently obfuscated or protocol-level variant of the exploit may not match a signature. The WAF reduces your attack surface during the patching window — it does not close the vulnerability. Patch first; treat the WAF as an additional layer, not a replacement.

Does PHP2Shell affect WordPress, Laravel, Drupal, and other PHP frameworks?

Yes — any PHP application is potentially vulnerable because the flaw is in the language runtime, not the application framework. This includes WordPress (which alone powers approximately 43% of all websites globally), Laravel, Drupal, Joomla, Magento/Adobe Commerce, Moodle, SugarCRM, and every other PHP-based platform. Framework or CMS version does not matter; the underlying PHP version is the only variable that determines exposure.

How was AI involved in discovering PHP2Shell, and what does that mean for defenders?

Wiz Research used OpenAI’s Codex Security tooling alongside manual analysis to trace complex use-after-free chains across PHP’s large C codebase — work that would previously have required months of specialist manual review. This is one of the most significant real-world demonstrations of AI-assisted vulnerability research discovering critical infrastructure-level flaws. The implication for enterprise defenders is significant: the capability that found PHP2Shell is now accessible to sophisticated threat actors too. AI-accelerated vulnerability discovery means that the time from “bug introduced” to “bug weaponised” will continue to compress, making rapid patch deployment and compensating controls more critical than ever.

Take Action Before Attackers Do

PHP2Shell is exactly the category of vulnerability that catches organisations off-guard — a critical flaw not in a product they consciously evaluated, but in the language runtime silently powering their entire web infrastructure. Understanding where PHP lives in your environment, how quickly you can deploy patches at scale, and what compensating controls exist in the meantime requires a mature asset inventory, tested patch workflows, and a practised incident response capability.

At P J Networks, we have spent over thirty years helping Indian enterprises build layered defences that remain resilient when the next critical zero-day lands — whether that’s a FortiGate IPS tuning engagement, a WAF deployment, a zero-trust architecture review, or a rapid vulnerability exposure assessment. If you want to know how exposed your organisation is to PHP2Shell and what your fastest path to remediation looks like, contact us today for a security assessment.

The post PHP2Shell (CVE-2026-109618 & CVE-2026-109619, CVSS 9.2): Critical PHP RCE Hits 70% of the Web — Emergency Patches Out Now appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

Who Is SafePay? A Closed Crew That Does Its Own Dirty Work

Most ransomware headlines in 2026 involve Ransomware-as-a-Service (RaaS) platforms — organisations like LockBit or Qilin that lease encryptors to affiliates. SafePay operates differently. Researchers at Picus Security describe it as a centralised, closed operation: the group writes its own malware, recruits no affiliates, and personally conducts every intrusion from initial access to ransom negotiation. That model means less operational noise and tighter OPSEC — attackers who know exactly what is on the victim’s network before they pull the trigger.

SafePay emerged in August 2024 and has accelerated dramatically through 2026. Its victim list spans North America, South America, Europe, Australia, and South and Southeast Asia. Double extortion is standard practice: data is exfiltrated before encryption, and victims who refuse to pay face publication on the group’s dark-web leak site.

The CVEs That Open the Door: Technical Breakdown

Advisory AA26-293A names five CVEs that SafePay operators exploit for initial access and lateral movement. These are not hypothetical — they appear in confirmed intrusion chains.

The Veeam flaws deserve special attention. CVE-2024-40711 allows a remote, unauthenticated attacker to execute arbitrary code on the Veeam backup server through a .NET deserialization chain. That single foothold gives SafePay access to every credential the backup solution has ever seen — credentials for vCenter, domain controllers, NAS devices, and cloud storage targets. The advisory notes that attackers immediately pivot from the Veeam compromise to enumerate the broader virtualisation environment.

CVE-2023-27532, the older Veeam flaw, extracts plaintext credentials from the Veeam configuration database — no password required, no exploit chain needed. Organisations that patched CVE-2024-40711 but skipped CVE-2023-27532 are not safe.

The Attack Chain: From VPN to Encrypted Domain Controller in Under 24 Hours

The advisory’s kill chain is consistent across confirmed intrusions. Understanding it is the first step to breaking it.

1. Initial access: Operators connect through Mullvad VPN exit nodes (making source attribution harder) and either exploit the VPN CVEs above or authenticate with credentials obtained through phishing or brute-force against exposed remote access portals.
2. Discovery: Standard Windows enumeration via net, nltest, and ADFind. The goal is to locate backup infrastructure and domain controllers within the first hour.
3. Credential access: Mimikatz is deployed to harvest cached credentials and Kerberos tickets from memory. Where Veeam is present, CVE-2024-40711 or CVE-2023-27532 yields every stored credential in one step.
4. Lateral movement: PsExec, WinRM, RDP, and ScreenConnect (legitimate remote-access tooling) are used for host-to-host movement. The use of signed binaries complicates EDR detection.
5. Exfiltration: Rclone, FileZilla, WinRAR, and 7-Zip transfer compressed archives to actor-controlled infrastructure. Double extortion depends on this step completing before encryption.
6. Backup sabotage: The Volume Shadow Copy Service is stopped (vssadmin delete shadows /all /quiet). Network-attached storage devices are reset to factory defaults, erasing all network shares and backup repositories.
7. Encryption: SafePay’s custom encryptor uses AES/ChaCha20 per-file with keys wrapped in RSA or x25519, and employs intermittent encryption to maximise throughput speed. Files receive a .safepay extension. Virtualised domain controllers are commonly targeted last — once encrypted, authentication across the estate collapses.

Why Backup Destruction Changes Everything

Traditional ransomware recovery advice — “keep offline backups, you’ll be fine” — assumes the attacker cannot reach your backups. SafePay’s playbook invalidates that assumption. By targeting the Veeam server first (because it holds every credential needed to reach everything else) and resetting NAS devices to factory defaults, the group systematically eliminates the organisation’s ability to recover without paying. CISA classifies this under ATT&CK technique T1490 (Inhibit System Recovery).

Indian enterprises with a single Veeam instance, network-connected NAS, and no air-gapped or immutable backup copy are particularly exposed. Cloud-connected backup to Azure or AWS is not immune either — if the Veeam credentials reach cloud storage, ransomware can delete those buckets too, unless immutability (object lock) is explicitly enabled.

This mirrors a pattern we have documented before in CVE-2026-105134 targeting AhsayCBS backup servers and in The Gentlemen Ransomware campaign — adversaries in 2026 are specifically engineering their attack chains to defeat recovery, not just encrypt data.

What You Should Do Right Now: Sanjay Seth’s Defensive Recommendations

As a practitioner who has hardened NOC and SOC environments across India’s enterprise, manufacturing, and financial sectors for three decades, here is the prioritised action list I would give any client facing this threat today:

1. Patch the Veeam CVEs — Today, Not This Sprint

Upgrade Veeam Backup & Replication to 12.3.0.310 or later, which resolves both CVE-2024-40711 and CVE-2023-27532. If a maintenance window is more than 48 hours away, firewall off port 9401 (the Veeam API port) at the perimeter and segment the backup server onto a dedicated VLAN with zero-trust micro-segmentation. No server in your network should be able to reach the Veeam API without explicit authorisation.

2. Patch or Replace SonicWall Appliances Running Vulnerable Firmware

CVE-2024-40766 affects SonicWall SSL-VPN and SonicOS Access Control — upgrade to the vendor’s indicated fixed versions immediately. Where upgrades are not possible within 24 hours, restrict management access and disable SSLVPN if it is not operationally required. Review SonicWall’s PSIRT portal for the current fixed-version matrix.

3. Implement Immutable Backups

At minimum, one backup copy must be immutable and offline or air-gapped. AWS S3 Object Lock, Azure Blob immutability policies, or dedicated tape rotation all qualify. Veeam’s Hardened Repository on Linux with immutability enabled is a viable on-premises option. Immutability must be enforced at the storage layer — not just by Veeam policy that the backup account can override.

4. Enforce MFA on All Remote Access Portals

The advisory is explicit: stolen credentials plus no MFA equals SafePay access. Every VPN, RDP gateway, and management interface must require a second factor. For organisations using FortiGate with FortiAuthenticator, configure RADIUS two-factor for SSL-VPN immediately and audit which accounts have saved passwords without MFA exemptions.

5. Block and Hunt for Mullvad VPN Exit IPs

CISA’s advisory includes a STIX/JSON IOC file with known Mullvad exit node IPs used by SafePay operators. Import these into your SIEM, EDR, and firewall deny lists. Also hunt retroactively — check the last 90 days of firewall and VPN logs for authentications from these prefixes. A successful login that nobody in your team can account for is a confirmed intrusion to investigate.

6. Restrict and Monitor Lateral Movement Tooling

SafePay relies on living-off-the-land binaries — PsExec, WinRM, ScreenConnect — that your own IT team likely uses. The defensive lever is behavioural baselining: alert on PsExec invocations outside business hours, WinRM connections from non-IT accounts, and Rclone or 7-Zip processes on servers. Application allow-listing (App Control in FortiEDR or Windows Defender Application Control) goes further by blocking unsigned executables entirely.

India Exposure: Why This Advisory Matters Here

India’s manufacturing and financial sectors have undergone rapid digitalisation, but backup hygiene has not kept pace. The 2023 CERT-In ransomware survey found that fewer than 40% of mid-market Indian firms had tested their backup restoration within the previous 12 months. SafePay’s model — compromise the backup first, encrypt second — is precisely calibrated to exploit that gap. India’s data-localisation mandate under the Digital Personal Data Protection Act also increases the blast radius of a successful double-extortion attack: breached personal data must be reported within 72 hours, and a simultaneous encryption-plus-exfiltration incident will easily exhaust that window before an incident response team is even engaged.

The advisory’s cross-sector victim list (finance, healthcare, manufacturing) maps directly onto sectors where P J Networks regularly engages. If your sector is in that list, assume you are in scope.

Frequently Asked Questions

Is SafePay a RaaS operation? Who are the operators?

No. SafePay is a closed, non-affiliate group — it develops its own encryptor, runs every intrusion directly, and does not recruit external affiliates. This distinguishes it from LockBit, Qilin, or Inc Ransom. The identity and nation-state nexus of the operators have not been publicly attributed in the advisory, though the group’s operational discipline and tooling sophistication suggest a well-resourced team.

Does patching CVE-2024-40711 fully close the exposure?

Patching removes the initial access vector for that specific flaw, but it does not expel attackers who are already inside. After patching, organisations should rotate all credentials stored in or accessible through Veeam, review Active Directory for new privileged accounts or group memberships, and audit authentication logs for the prior 90 days. Additionally, CVE-2023-27532 should be patched in the same window — both flaws target Veeam and are listed in the same advisory.

What does the .safepay extension look like in practice, and can files be recovered without paying?

Encrypted files receive a .safepay appended extension (e.g., annual-report.xlsx.safepay). The encryption uses per-file AES or ChaCha20 keys wrapped with RSA or x25519 — no public decryptor exists. Recovery without paying the ransom requires clean, pre-attack backups that were not reachable from the compromised backup server. This is why immutable, air-gapped backups are the only viable recovery option.

How quickly does SafePay move from initial access to ransomware deployment?

Confirmed incident timelines from the advisory’s supporting cases show a sub-24-hour window from first access to encryption initiation in multiple intrusions. This is significantly faster than older ransomware groups (which typically dwelt for weeks). Automated initial recon, pre-staged tooling, and the Veeam pivot — which hands the attacker every credential at once — compress the dwell time dramatically. Alert thresholds tuned for multi-day incidents will miss SafePay.

Conclusion: Test Your Backups Before SafePay Does

The SafePay advisory is unusual in its breadth — five agencies, four countries, 600-plus confirmed victims in two years — and in its specificity: it names the exact CVEs, tools, and techniques used in real intrusions. For organisations in India’s critical infrastructure, manufacturing, or financial sectors, this is not background noise. It is a blueprint of how your environment may already be targeted.

The single most important action is to validate your backup recovery chain today — not next month, not next sprint. Specifically: verify that at least one backup copy is immutable and unreachable from your primary domain, rotate Veeam service account credentials, and confirm MFA is enforced on every remote access portal. Then patch the five CVEs in the table above in CVSS order.

If you need expert eyes on your backup architecture, remote access posture, or incident response readiness — or if you are not sure whether your SOC would catch a sub-24-hour intrusion — reach out to Sanjay Seth at P J Networks for a no-obligation security assessment. With three decades of hands-on network and security architecture experience across India, we will tell you exactly what your exposure looks like — and how to close it before the ransom note appears.

The post SafePay Ransomware: FBI & CISA Warn of 600+ Victims and Backup Destruction — CVE-2024-40711 Exploited appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

Tracked as CVE-2026-106173, rated CVSS 9.8 Critical, and catalogued under Fortinet’s own advisory FG-IR-26-180, this flaw lives in FortiSIEM’s internal gRPC query service. Horizon3.ai, the firm that discovered and documented it, released both a technical deep-dive and a PoC script (CVE-2026-106173.py) that requires only a target IP address and a command to execute. The barrier to exploitation just dropped to zero.

Key Takeaways

• Public PoC for CVE-2026-106173 (CVSS 9.8) dropped October 20, 2026 — active exploitation is now almost certain.
• The attack is fully unauthenticated: no credentials, no prior access, no user interaction required.
• Entry point is TCP port 27918 (FortiSIEM gRPC phQueryMaster). If that port faces the internet, you are one command away from being compromised.
• Affected: FortiSIEM 7.0.0 through 7.5.0. Fix: upgrade to 7.5.1 (or 7.6.0 for older branches). FortiSIEM Cloud is not affected.
• Interim workaround: immediately restrict access to TCP port 27918 from all untrusted networks.
• A compromised SIEM is uniquely catastrophic — attackers gain both a foothold and the ability to suppress their own detection alerts.

What Is FortiSIEM and Why Does It Make Such a High-Value Target?

Fortinet FortiSIEM is an enterprise security information and event management platform — the aggregation point for security logs, alerts, and compliance reports across an entire organisation’s infrastructure. Thousands of enterprises globally, including many in India’s BFSI, government, and critical infrastructure sectors, run FortiSIEM as the nerve centre of their SOC operations.

That centrality is precisely what makes it so dangerous to compromise. When an attacker gets remote code execution on your SIEM, they do not merely get one more server. They gain:

• Full visibility into every security event your organisation is generating
• The ability to delete, suppress, or falsify log data
• Credentials, API keys, and connection strings for every integrated data source
• A trusted pivot point — SIEMs are typically placed deep inside network segments with broad read access to production systems

This is why attackers specifically seek out SIEM and network management infrastructure. It is the ultimate blind-spot creator: once your SIEM is compromised, your SOC operators are effectively flying without instruments. For organisations that have invested in Fortinet’s Security Fabric — FortiGate, FortiAnalyzer, FortiAuthenticator — a FortiSIEM breach is not a peripheral incident. It is a core infrastructure compromise.

CVE-2026-106173: Technical Breakdown of the Exploit Chain

The Attack Surface: gRPC on Port 27918

FortiSIEM runs an internal gRPC service called phQueryMaster on TCP port 27918. This service is designed for node-to-node query traffic between FortiSIEM workers — it is internal plumbing, not a customer-facing interface. Critically, however, Fortinet did not require client-certificate authentication on this service, meaning any network-reachable client can connect to it without presenting credentials.

In principle, this is acceptable if port 27918 is properly firewalled from untrusted networks. In practice, many deployments expose it to at least the internal LAN — and some have it reachable from the internet. The Horizon3.ai PoC works as long as the port is reachable.

Stage 1: Path Traversal via Unsanitised query-id

The gRPC service exposes a remote procedure call named SendQueryResult. The handler for this RPC builds an output file path by concatenating an attacker-supplied query-id value directly into a directory string — /opt/phoenix/query/result/<query-id>-result-.dat — with no validation whatsoever.

An attacker supplying a query-id of ../../../../../../../tmp/evil walks the write out of the intended results directory and into any location on the filesystem where the FortiSIEM process has write access — which, given the service runs with elevated privileges, is nearly everywhere.

Stage 2: Null-Byte Injection to Strip the Forced Suffix

The server appends its own suffix (-result-.dat) to every filename, which would ordinarily prevent an attacker from writing to a specific filename needed for code execution (for example, a PHP webshell or an SSH authorized_keys file). Horizon3.ai defeated this control with a null-byte injection: by embedding a null byte (\x00) in the query-id field through gRPC’s HTTP/2 and HPACK encoding layers, the operating system’s open() call interprets the null byte as end-of-string and silently discards the server’s suffix.

Result: the attacker controls both the path (via traversal) and the filename (via null-byte truncation) of the file being written. Arbitrary file write becomes arbitrary code execution by overwriting a cron job, an SSH key, or a web-accessible script.

The Horizon3.ai PoC: What It Does

The public PoC published by Horizon3.ai is a Python script that accepts a target host, a port (defaulting to 27918), and an OS command. It:

1. Connects unauthenticated to the FortiSIEM gRPC service
2. Crafts a malicious QueryResultReq packet embedding both path traversal and null-byte sequences
3. Writes a file to an attacker-chosen location on the server
4. Triggers execution via an accessible entry point

The full root-cause analysis and exploit walkthrough are published on the Horizon3.ai Attack Research blog. The PoC repository is live on GitHub. Detection-evasion has not been built in — but nation-state actors will wrap this in hours, if they have not already.

Affected Versions at a Glance

Source: Fortinet PSIRT Advisory FG-IR-26-180 | NVD CVE-2026-106173

What You Should Do Right Now — Sanjay Seth’s Expert Recommendations

With a working public PoC now available, the window between “patch advisory” and “active mass exploitation” has collapsed to hours. Here is the prioritised response plan I would walk any client through today:

Immediate (Within the Hour)

• Block TCP port 27918 externally — right now. Use your FortiGate, ACL, or cloud security group to deny all inbound traffic to port 27918 from any untrusted network. Fortinet’s own advisory confirms that “restricting access on TCP port 27918 prevents the issue.” This is your fastest risk reduction before you can patch.
• Audit your FortiSIEM version. Log into the FortiSIEM UI, go to Admin → System Configuration → System, and confirm your running version. Match it against the table above.
• Check exposure. Run nmap -sV -p 27918 <your-fortisiem-ip> from an external vantage point to confirm whether port 27918 is reachable from outside your trusted network segments.

Short-Term (Within 48 Hours)

• Apply the patch. Upgrade FortiSIEM to 7.5.1 if you are on 7.5.0. If you are on any version from 7.0 through 7.4, upgrade to 7.6.0 or above. Test in a non-production environment where possible, but do not let testing delay patching production.
• Threat-hunt for compromise indicators. Before patching, check for:
  • Unexpected files in /tmp, /var/tmp, or web-accessible directories
  • New or modified cron jobs, SSH keys, or startup scripts
  • Unusual outbound connections from the FortiSIEM host
  • Any gRPC traffic on port 27918 from unexpected source IPs in your network logs
• Rotate credentials. FortiSIEM holds API credentials for every integrated system. If you suspect any exposure window, rotate the service accounts FortiSIEM uses to query FortiGate, Active Directory, cloud platforms, and ticketing systems.

Strategic (This Month)

• Network-segment your SIEM. The FortiSIEM management interface and internal gRPC ports should never be reachable from general office or guest networks. Place FortiSIEM in a dedicated management VLAN with explicit allow-list rules. This is zero-trust network access applied to your monitoring infrastructure.
• Review all Fortinet product versions. CVE-2026-106173 is not an isolated incident — 2026 has seen critical flaws in FortiGate, FortiMail, and FortiSandbox. Run a full Fortinet product audit and ensure every component is current.
• Verify your SIEM’s integrity. Even if you were not exploited this time, this incident is a prompt to verify that your SIEM itself is covered by your integrity-monitoring and backup strategy. Who watches the watchmen?

Why a Compromised SIEM Is Uniquely Catastrophic for Indian Enterprises

India’s IT-GRC landscape operates under a tightening regulatory framework: SEBI’s cybersecurity circular, RBI’s IT risk guidelines, CERT-In’s 6-hour breach-reporting mandate, and the Digital Personal Data Protection (DPDP) Act all presuppose that organisations have functioning, reliable audit logs. A compromised SIEM that has been silently altering or deleting log data creates not just a security crisis but a compliance crisis.

Indian enterprises in BFSI, telecom, and critical infrastructure that rely on FortiSIEM for their regulatory audit trails should treat CVE-2026-106173 as a board-level issue, not a patching ticket. The downstream consequences of undetected log tampering can include regulatory findings, licensing risks, and — critically — an inability to prove the scope of any concurrent breach during an incident investigation.

It is also worth noting the persistence risk. Once an attacker has unauthenticated RCE on a FortiSIEM server, they can establish persistence through multiple channels — cron jobs, webshells, modified startup scripts — none of which patching alone will remove. If you have any doubt about whether your FortiSIEM was compromised before you patch, treat it as a forensic evidence-preservation scenario first and a patching scenario second.

Frequently Asked Questions

Does blocking port 27918 break FortiSIEM’s functionality?

Port 27918 is used for internal gRPC communication between FortiSIEM worker nodes in a distributed deployment. If you are running a single-node FortiSIEM deployment, blocking this port from external/untrusted networks will not affect functionality. In a multi-node (distributed) deployment, you should only block the port from untrusted networks; traffic between your own FortiSIEM nodes on your internal network should be allowed via a specific allow-list ACL rather than blocking the port entirely. Consult your network diagram before applying blanket blocks — and then patch immediately to remove the dependency on the workaround.

Is there evidence of active exploitation in the wild?

As of October 21, 2026, there are no publicly confirmed in-the-wild exploitation incidents. However, the Horizon3.ai PoC was published only yesterday (October 20), and history shows that with a working, public exploit for a CVSS 9.8 unauthenticated RCE, mass scanning and exploitation attempts typically begin within 24–72 hours. CISA has not yet added CVE-2026-106173 to its Known Exploited Vulnerabilities catalog, but that typically lags behind actual exploitation by days to weeks. Do not wait for KEV confirmation before acting.

My FortiSIEM is on version 7.4.x — do I need to jump directly to 7.6.0?

Yes. Fortinet’s advisory specifies that for version branches 7.0 through 7.4, the fix is to upgrade to FortiSIEM 7.6.0 or above. Version 7.5.1 only addresses the issue for the 7.5.x branch. Check with your Fortinet partner or Fortinet Support for the upgrade path from your specific version. FortiSIEM 7.6.x is not affected by this CVE.

We use FortiSIEM Cloud — are we affected?

No. Fortinet has confirmed that FortiSIEM Cloud is not affected by CVE-2026-106173. The vulnerability is specific to on-premises deployments. Cloud tenants should continue standard hygiene practices but do not need emergency action for this specific CVE.

The post CVE-2026-106173 (CVSS 9.8): Public PoC Drops for FortiSIEM Unauthenticated RCE — Patch or Block Port 27918 Now appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

What makes this incident particularly worrying is the attacker’s method. They did not crack Siemens’ servers or tamper with the installer package. Instead, they weaponised trust itself — distributing a legitimate, digitally-signed copy of the Siemens executable alongside attacker-controlled DLL files, tricking Windows into loading malicious code under the application’s own privileges. In environments where Siemens software carries implicit “approved by IT” status, that signature is a skeleton key.

What Is CVE-2026-110936 — and Why Does It Matter for OT/ICS Environments?

Siemens Software Center (SSC) is the single pane of glass for downloading, installing, licensing, and updating Siemens products — from SIMATIC WinCC and TIA Portal to STEP 7 and Automation Designer. In a typical Indian manufacturing or energy plant, SSC is installed on every engineer workstation and often on shared “update servers” that push software to OT networks.

The flaw, tracked as Siemens Security Advisory SSA-580366, is classified as CWE-427: Uncontrolled Search Path Element. When Windows launches the SSC executable, it searches a list of directories for required DLL files. Because the application does not pin the full path of each dependency, an attacker who places a maliciously-named DLL in a directory that appears earlier in the search path — such as the same folder as the executable, or a location a standard user can write to — can cause Windows to load their code instead of the legitimate library.

Critically, this exploit works without administrator rights, without a network connection, and without breaking Siemens’ code-signing certificate. The Siemens executable itself remains untouched and validly signed; only the adjacent DLL is attacker-controlled.

The Romulus ClickFix Attack Chain: How It Works

ClickFix is an attacker technique that has surged in 2026. Rather than exploiting code, it exploits human psychology — presenting users with a fake “fix required” prompt that asks them to paste a PowerShell or terminal command, ostensibly to resolve a software error. In the Romulus variant linked to this campaign, the delivery method is more surgical:

1. Lure delivery: The victim receives a phishing email, a compromised site redirect, or a Telegram/WhatsApp message instructing them to download Siemens software from what appears to be a legitimate source. The downloaded archive contains the genuine, signed Siemens Software Center binary.
2. Malicious DLL placement: Alongside the genuine binary, the archive silently drops one or more attacker-crafted DLL files — named to match libraries SSC loads at startup — into the same directory or a writeable path the application searches.
3. DLL sideloading: When the user launches Siemens Software Center (a routine, trusted action), Windows resolves the DLL search path, finds the malicious DLL first, and loads it under the SSC process context. The Siemens application window opens normally — the user sees nothing amiss.
4. RAT execution: The malicious DLL spawns a Remote Access Trojan in the background. From this foothold, attackers can exfiltrate credentials, establish persistence, and pivot deeper — including into connected OT or SCADA networks.

The digital signature of the SSC executable remains valid throughout. Traditional antivirus tools and application control policies that whitelist by signature alone will not catch this. This is why behavioural detection, DLL load monitoring, and zero-trust application control are now essential layered defences.

The ICS/OT Risk: Why Indian Manufacturers Must Act Fast

India is Siemens’ fourth-largest global market. Siemens automation technology is embedded in steel plants in Odisha, textile mills in Tamil Nadu, pharmaceutical GMP lines in Himachal Pradesh, metro rail networks in Delhi and Hyderabad, and power distribution substations across the country. In most of these environments, engineer workstations sit at the IT/OT boundary — they connect to both corporate email (where phishing arrives) and to the PLC/DCS network (where damage is done).

An attacker who achieves RAT persistence on a Siemens Software Center host in a manufacturing plant could:

• Harvest credentials for TIA Portal, WinCC, or SCADA dashboards
• Silently modify PLC logic or historian configurations
• Stage ransomware against both IT and OT segments simultaneously
• Exfiltrate production data, IP, or safety parameters to a foreign adversary

This is not theoretical. As we reported last week on the Danfoss OT cyberattack, OT-targeting campaigns are escalating in both frequency and sophistication. The attack chain exploiting CVE-2026-110936 shows that adversaries no longer need to hack OT protocols — they can ride in on a trusted software update tool.

Technical Breakdown: DLL Sideloading in Depth

DLL sideloading exploits the Windows DLL search order (as documented in Microsoft’s documentation). By default, when an application calls LoadLibrary("example.dll") without specifying an absolute path, Windows searches:

1. The directory from which the application loaded
2. %SYSTEMROOT%\System32
3. %SYSTEMROOT%
4. The current working directory
5. Directories in the PATH environment variable

Because SSC does not use Safe DLL Search Mode or absolute path references for all dependencies, placing a malicious DLL in the application directory is sufficient to hijack execution. Modern mitigations like KnownDLLs registry keys and DLL redirection only protect a fixed set of system libraries — custom or product-specific DLLs are not covered.

Detection indicators to hunt for in your SIEM:

• Siemens Software Center process (SiemensSoftwareCenter.exe) spawning unexpected child processes (PowerShell, cmd, wscript)
• DLL loads from the SSC application directory that are not signed by Siemens AG
• Outbound connections from SiemensSoftwareCenter.exe to non-Siemens IP ranges or domains
• New scheduled tasks or registry run keys created shortly after SSC execution

What You Should Do Right Now — Sanjay Seth’s Defensive Playbook

This is an actively exploited, high-severity vulnerability confirmed less than 24 hours ago. Here is the prioritised action plan for Indian IT leaders and security practitioners:

Immediate (within the hour)

• Patch SSC to 4.0.9.8 — This is the primary fix. The update deploys automatically the next time a user launches Siemens Software Center. In managed environments, push this centrally via Siemens Automation License Manager, WSUS, or your endpoint management platform rather than waiting for each user to open the app organically.
• Block execution of older SSC versions — Use AppLocker or WDAC rules to prevent SiemensSoftwareCenter.exe from launching if its version is below 4.0.9.8.
• Block the Romulus IOCs — Obtain the indicator list from Siemens SSA-580366 and push them to your firewall, proxy, and EDR immediately.

Short-Term (within 24 hours)

• Hunt for compromise — Query your EDR and SIEM for the detection indicators listed above. Look back at least 14 days, covering the period between advisory publication (15 Oct) and the exploitation confirmation (19 Oct).
• Isolate engineer workstations with OT access — Temporarily quarantine any Siemens-managed endpoint that has both internet access and a live OT/SCADA connection until you confirm it is clean and patched.
• Enable DLL load auditing — Configure Windows Defender Application Control (WDAC) or Microsoft’s Process Mitigation options to alert on unsigned DLL loads in the SSC process.

Strategic (within the week)

• Review your software download policy — Ensure engineers download Siemens software only from the official support.industry.siemens.com portal, not from third-party mirrors or peer-shared archives.
• Apply zero-trust principles at the OT boundary — As detailed in our zero-trust campus architecture guide, engineer workstations should be micro-segmented from the OT network with FortiGate firewall policies enforcing least-privilege communication.
• Enable application control on FortiGate — Use FortiGate’s IPS and application control policies to detect and block lateral movement from compromised engineer hosts into OT VLANs.
• Train your team on ClickFix lures — Show your IT staff and engineers what a ClickFix prompt looks like. The social engineering component is as important to address as the technical patch.

As a zero-trust and FortiGate specialist, I have been advocating for strict micro-segmentation between IT and OT networks since long before incidents like this became commonplace. CVE-2026-110936 is a powerful reminder: the threat does not always arrive through the firewall — sometimes it walks in through the front door wearing a trusted badge.

Siemens’ Response and the Wider Supply-Chain Lesson

Siemens deserves credit for transparency here. Advisory SSA-580366 was published within days of researcher Jose Oregon’s disclosure via Huntress Labs. The auto-update mechanism in SSC 4.0.9.8 means patching is frictionless for users with internet-connected workstations. Siemens also confirmed its own infrastructure was not compromised — the attack exploits a client-side trust assumption, not a server-side weakness.

But the incident raises a question every enterprise must now ask: How many other signed, trusted vendor tools in your environment might have a similar DLL search order issue? Security researchers at Help Net Security and SecurityWeek note that ClickFix-style campaigns are increasingly targeting signed industrial and enterprise software precisely because the trust barrier is lower and detection is harder.

The Canadian Cyber Centre issued advisory AV26-1063 on 19 October urging all Canadian organisations using SSC to patch immediately — a signal that this campaign is not geographically limited. India, as one of the world’s largest Siemens software consumers, is equally in scope.

Frequently Asked Questions

Is my Siemens Software Center automatically patched?

If SSC is open and internet-connected, it will update automatically the next time it is launched. However, if the application is not opened regularly (common on infrequently-used engineer laptops), the update will not be applied. You must actively verify the version is 4.0.9.8 across all endpoints — do not assume auto-update has run.

Does this affect PLC firmware, TIA Portal, or SIMATIC hardware directly?

CVE-2026-110936 affects Siemens Software Center, the update management client, not PLC firmware, TIA Portal itself, or SIMATIC hardware. However, an attacker who achieves code execution on an engineer workstation via this flaw has a foothold that can be used to attack those adjacent systems. Treat a compromised SSC host as a potential pivot point for the entire OT network.

We don’t use SSC — do we need to do anything?

If your organisation does not use Siemens automation products, you are not directly affected. However, third-party contractors, system integrators, and remote OT vendors who connect to your network may have SSC installed. Audit contractor laptops and verify that any device with OT network access is clean before the next on-site visit.

How does ClickFix evade our existing security controls?

ClickFix campaigns are specifically designed to bypass signature-based AV (by using a signed legitimate binary), email gateway scanning (the malicious DLL is often hosted on a legitimate file-sharing service), and user training that focuses on malicious attachments (the “fix” prompt appears in-browser or in a legitimate-looking notification). Behavioural EDR, DLL load telemetry, and zero-trust application control are the controls that catch it — perimeter defences alone will not.

The post CVE-2026-110936 (CVSS 8.4): ClickFix Campaign Hijacks Siemens Software Center — Patch OT Endpoints Now appeared first on Sanjay Seth — Cybersecurity & Network Consultant.