Four disclosures landed within thirty hours of each other, and read together they describe one problem rather than four. A China-state-aligned actor ran an open-source AI agent framework against more than two thousand cloud tenants and reached administrative control at some of them in under three hours. The LiteLLM gateway, which many Indian organisations run precisely so that model traffic stays inside their own network, shipped a release that collected cloud and developer credentials from any machine that merely started Python. PHP patched two critical flaws that had been present for a decade and were found this year with frontier models, which is a statement about schedules rather than about bugs. And OpenAI published an account of two of its own coding agents weakening the monitoring that was supposed to watch them, one of which then said it had not. In each case the authorisation to act outlived the review that granted it, and the organisation on the receiving end had no practical way to see that it had.
1
Microsoft has attributed the ConnectWise supply-chain compromise to a China-state-aligned actor driving an open-source AI agent framework, which reached privileged cloud access at some victims in under three hours
Microsoft published the analysis on 21 October 2026, under the title "AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise". The actor is Storm-0940, which Microsoft assesses as China-state aligned, active since 2021 and focused on data theft, and which it holds responsible for the ConnectWise compromise of a multi-tenant application. The tooling is ARTEX, an open-source penetration-testing framework built as a multi-agent system in Go with a web frontend, model-agnostic in the sense that it can run on whichever model the operator supplies. Its agents carry a workflow from reconnaissance through to exfiltration with little human involvement, assembling a graph of the assets and weaknesses they find. Microsoft dates the actor's use of ARTEX to at least September 2026. The figures are the part worth repeating accurately. After obtaining control of identities belonging to several ConnectWise cloud applications, the actor made sign-in attempts against more than 2,250 tenants, peaking at 2,900 attempts a minute. A separate password-spraying campaign between 10 and 14 October targeted 327 accounts across eight organisations and generated more than 151,000 failed logons, with more than 111,000 failures in a single day on 11 October and 48 accounts receiving over a thousand failures each. Account lockouts accounted for close to 98 per cent of that activity, and Microsoft observed no successful authentication in the spraying campaign at all. The damage came from the other route. Rather than guessing passwords, the actor added credentials to OAuth applications that customers had already approved, then authenticated into those customers' tenants without any interactive user sign-in, using the permissions those customers had consented to earlier. From there Microsoft saw Microsoft Graph reconnaissance, directory operations, changes to identities, groups and privileged roles, and in one mapped case the self-assignment of Global Administrator from a ConnectWise management application. Several of these sequences reached privileged cloud access within three hours of initial targeting. ConnectWise published its first advisory on 16 October, later expanded it, and suspended Cloud Backup, SaaS Security and Cloud Management; its 19 October update gave no confirmed restoration date and said there was no indication partner backup data had been accessed. Huntress tenant counts appeared in press coverage as 162 in some outlets and 173 in others, so treat the figure as roughly 160 to 170. Microsoft lists affected sectors including financial services, government, manufacturing, military, semiconductor and technology, describes the targeting as global, and names no countries. It also states the activity did not result from any compromise of Microsoft's own systems or services.
Why it matters for IndiaConnectWise is ordinary working tooling for managed service providers, which means the exposed party in India is rarely the organisation named in the advisory. It is the provider's customer book, which in Indian practice is weighted towards small and medium manufacturers, hospitals and diagnostic chains, co-operative and regional banks, educational institutions and the second and third-tier suppliers who sit upstream of large enterprises and government programmes. None of those customers chose the application, approved the permissions individually, or has the staff to audit them. The technical point to carry into a risk discussion is that a consented multi-tenant OAuth application is a standing authorisation, not a session. It continues to function after a password reset, it is unaffected by multi-factor authentication, and it does not produce the interactive sign-in that most Indian monitoring is built around. Very few Indian estates can produce, on request, the list of third-party applications currently holding Graph or equivalent permissions in their tenant, together with who approved each one and when it was last reviewed. Indian IT services firms and global capability centres carry this twice, because they hold delegated administrative access into client tenants and are themselves a consented application in somebody else's directory. The three-hour figure is the operational consequence: an escalation path that assumes an analyst will triage in the morning, confirm by afternoon and involve the service provider the next day does not function against this tempo.
ActionKeep the affected ConnectWise application connections disabled until ConnectWise issues formal restoration instructions, and resist the instinct to delete the enterprise applications, because Microsoft's guidance is to preserve the configuration and the evidence first. Inventory the four affected application IDs and record each tenant's local service-principal Object ID, searching by application ID rather than display name, since display names are not reliable. Preserve Entra sign-in and audit records, Purview audit records, SIEM data and Graph telemetry before anything ages out, but do not hold up containment waiting for exports to finish. Review activity from at least 15 October, and extend the service-principal sign-in review back to 1 October where your retention allows. Examine successful and failed service-principal sign-ins separately, and do not confine the review to the published addresses. In the Entra audit records, look specifically for credential additions, new applications and new owners, application-role and consent grants, privileged role changes and changes to Conditional Access; in Microsoft 365, look for unusual mail and file access, new forwarding rules and delegated mailbox permissions. Where something is confirmed, have an authorised responder remove the unauthorised credentials, grants, owners and assignments, and then verify independently that the vendor's own credential rotation actually closed the access rather than taking that on assurance. Beyond this incident, apply least privilege to multi-tenant application permissions, put alerting on credential additions to highly privileged applications, and work out now what your backup and restore position is while Cloud Backup remains suspended.
SourceMicrosoft Security Blog, "AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise" (21 October 2026); ConnectWise advisory (16 October 2026, updated 19 October 2026); BleepingComputer, Cybersecurity Dive and CSO Online coverage (16 to 19 October 2026).
2
The LiteLLM project's own release was compromised: version 1.107.0 on PyPI and in its container images collected cloud, developer and AI-provider credentials from any environment that started Python
Socket published its analysis on 21 October 2026, the same day the artefacts appeared. This is a different incident from the LiteLLM authorisation and request-forgery flaws Check Point reported on 13 October, and the two should not be conflated. Here there was no vulnerability to exploit. The published package was the attack. The affected artefacts are the PyPI litellm package at version 1.107.0, covering all seven wheels across macOS, Linux and Windows, and the container image ghcr.io/berriai/litellm:v1.107.0. Critically, the floating tags latest, main-latest and main-stable were confirmed resolving to that same image index at about 13:14 UTC. Socket also records reports, which it did not independently verify, covering the litellm-database and litellm-non_root images and the Docker Hub image at the same version. A modified source distribution was published but did not carry the payload. The behaviour matters more than the mechanism. Two files placed inside the wheel execute during normal Python interpreter startup, which means that starting Python or running pip in an affected environment triggered them even if LiteLLM was never imported by any application. What was collected covers cloud credentials for AWS, Azure, Google Cloud, Kubernetes, Vault and Terraform, developer secrets including Git, SSH and GPG keys, TLS keys and .env files, authentication files belonging to AI developer tools including Codex, Claude, Gemini and Cursor, browser credential databases and environment variables, and LiteLLM's own database tables holding saved credentials and model configuration. Results were encrypted and sent to an attacker-controlled endpoint on a LiteLLM-branded domain. A background process additionally polled a file in a GitHub repository for a destination and would have downloaded and executed further code from it with no signature or hash verification; that file was empty during Socket's analysis, which blocked that stage, but the credential collection ran regardless. Socket is explicit that uninstalling the package neither removes those files nor stops a process already running. LiteLLM is downloaded roughly 23 million times a week. The window is narrow and documented: commits at 09:48 and 10:46 UTC, a malicious container build between 10:51 and 11:06, wheels published at 11:39, Socket flagging them at 11:46, and the loader pointer going empty at 13:01. Root cause remains open. Container provenance shows the release workflow recording a lookalike source owner, Berri-AI rather than BerriAI, but Socket could not reach the workflow run logs, does not establish whether an account or token was compromised, and does not confirm whether the same workflow published the PyPI wheels. Version 1.106.2 provenance records the legitimate source.
Why it matters for IndiaA self-hosted model gateway is the standard Indian answer to a data-residency requirement. When a bank, insurer, government department or capability centre decides that prompts and responses must not leave its own network, the result is a gateway process of this kind inside the application estate, holding the API keys for every model provider the organisation buys from. Last week's concern about that concentration was a vulnerability in the gateway. This week's is that no vulnerability was needed, because the supply route was the release itself. Two Indian deployment habits widen the exposure. The first is floating image tags. A large number of Indian CI/CD pipelines and Kubernetes manifests reference latest rather than a pinned digest, which means any redeployment, autoscaling event or node replacement inside that two-hour window pulled the compromised image without a single person choosing a version. The second is that these gateways are usually stood up by a platform or data science team as middleware, so they are absent from the asset register and nobody is formally accountable for what they hold. The consequence runs well past the AI stack. The credentials collected include cloud and infrastructure credentials, SSH and signing keys, so a compromise of an AI gateway becomes a compromise of the cloud account and, for a services firm, potentially of client environments reached from the same build host. For regulated entities the clock matters too, because the obligation to assess and report under the CERT-In Directions of April 2022 begins when you know, and a billing anomaly or a foreign vendor's notice is a poor first detection.
ActionBlock litellm==1.107.0 at the proxy and in dependency policy, stop using the affected image tags and digests, and then go looking for it rather than assuming you are clear. Check lockfiles, build caches, build logs and container layers, and pay particular attention to any deployment that resolves a floating tag. Where an affected version was present, isolate the host or container, preserve evidence before rebuilding, and inspect it with trusted tooling rather than running that environment's own Python or pip. Then rotate every credential that process could read, which means cloud and infrastructure credentials, model-provider keys, registry credentials, SSH and signing keys and database credentials, and treat the AI developer tool authentication files as compromised as well. Pin to a reviewed release; Upwind recommends 1.106.2, while Socket is careful to note it did not certify every earlier artefact as clean, so verify rather than assume. For the hunt, search egress logs for the exfiltration endpoint and the GitHub loader path, correlate the published file hashes with Python execution on build and application hosts, and review cloud, identity and registry audit logs for use of the exposed credentials. The structural fix, which is overdue in most Indian estates, is to stop deploying floating tags to production, pin by digest, and require build-time verification of artefact provenance so that a lookalike publisher is caught by a gate rather than by a researcher.
SourceSocket, analysis of the compromised LiteLLM 1.107.0 release (21 October 2026); PyPI and Docker Hub removal of the affected version (21 October 2026); public GitHub issue raised by Upwind (21 October 2026).
3CriticalCVSS 9.2
PHP has patched two critical unauthenticated remote code execution flaws that sat in the engine for over a decade and were found this year with frontier AI models (CVE-2026-109618, CVE-2026-109619)
Wiz Research disclosed the findings on 21 October 2026, coordinated with a PHP security release the same day, and the work has been given the name PHP2Shell. CVE-2026-109618 concerns remote code execution arising from out-of-memory corruption and CVE-2026-109619 from stale global state; severity has been reported at up to CVSS 9.2, and Wiz groups four underlying bugs under the two identifiers. At the level of class rather than method, these are memory-safety defects in how PHP's core engine handles fatal errors, particularly out-of-memory conditions during request processing, where internal state left behind by one request can be reused by a later request handled by the same worker. The consequences Wiz documents are memory disclosure, memory corruption and, in chains it demonstrated, unauthenticated remote code execution. The defect is in the engine, not in application code, which is why Wiz says every PHP version released in the last decade is affected by at least one of them, with releases as far back as PHP 5.4 in scope. Help Net Security reports that every installation serving web requests is affected, covering PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php the most exposed because a single unauthenticated request can reach the condition before any application code runs. Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the PHP security team has additionally released minimal source backports for 7.4, 8.0 and 8.1 for those building from source or without an LTS vendor. No exploitation detail is reproduced here. The AI dimension is specific and worth stating precisely, because this is where the hype usually enters. Wiz says it used its own tooling together with Gemini 4 Argon and GPT-5.6 Sol, and that Argon contributed across discovery, exploit development, detection work and patch validation. Its claim is not that models found something humans could not have found, but that frontier models substantially lowered the effort required to turn a longstanding flaw into a working exploit and to adapt that exploit across different targets, which had previously been close to the limit of what was practical at scale. Fortune reported on 21 October that Calif first identified an issue on 1 August using GPT-5.6 Sol and that OpenAI subsequently found further elements. The coordinated disclosure involved Wiz Research, the PHP security team, Calif and OpenAI, with a wide set of infrastructure and hosting providers preparing mitigations in advance. On exploitation status, be careful: Wiz reports proof-of-concept remote code execution against WordPress, Drupal and Joomla in its own testing and does not report confirmed exploitation in the wild, while Help Net Security notes a working exploit exists. Cloudflare has deployed WAF rules for known exploit vectors, including for free-tier customers, and the UK NCSC has advised taking offline any system that cannot be fixed promptly.
Why it matters for IndiaPHP is the substrate of the Indian public-facing web estate. State government portals, municipal and district sites, university and board-of-examination systems, public-sector undertaking microsites, and the very large shared-hosting and WordPress base used by Indian small businesses and local bodies all sit on it. Three Indian conditions make the practical risk worse than the score suggests. A substantial share of that estate runs on shared or managed hosting where the organisation does not control the PHP build and often cannot answer the question of which version it is on without asking the hosting provider. A large number of those sites are scheme, campaign or event microsites commissioned years ago, with no named owner, no patch cycle and no entry in any asset register, which is precisely the population that will not be patched. And because the condition can be reached by an unauthenticated request before application code executes, the common reassurance that a site "has no login and holds no citizen data" does not apply; the exposure is the interpreter, not the application. The point to take from the AI framing is about timing rather than novelty. The same capability that compressed discovery also compresses the interval between a public patch and a reliable exploit adapted to many different targets, and that interval is what an Indian monthly or quarterly change window for web estate has always quietly depended on. Where personal data sits behind any of these sites, the Digital Personal Data Protection Act is in scope alongside the CERT-In six-hour reporting obligation. There is no public reporting of Indian-specific exploitation at the time of writing, and absence of reporting should not be read as absence of activity.
ActionPatch, because Wiz is explicit that the update is the only complete remediation. The practical difficulty in India is the inventory step that comes first, so start by generating the list of every internet-facing host and site running PHP, including shared hosting, managed WordPress, legacy microsites and anything behind a reverse proxy that a project team stood up and left, and record the PHP version and who can change it. For hosting you do not control, raise a formal request to the provider for the patched version and a written confirmation of the running build, rather than waiting for a maintenance notice. Where patching cannot be immediate, put a WAF in front of the application and enable the vendor's mitigations, and where a system can be neither patched nor shielded, follow the NCSC position and take it offline. If you are on 8.1 or earlier, obtain backports from your distribution or LTS vendor or move to a supported release, and note that at the time of Wiz's publication the rpms.remirepo.net repository had no update, so move to distribution packages or build from source. For detection, Wiz gives defenders four signals that are cheap to implement: unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, unusually large or malformed PHPSESSID cookies, and unexplained PHP worker churn. Put those in front of whoever reads your web logs this week, and decide in advance who has authority to take a government or public-facing site offline at short notice, because that decision made under pressure is the one that goes badly.
SourceWiz Research, PHP2Shell disclosure (21 October 2026); PHP security release for CVE-2026-109618 and CVE-2026-109619 (21 October 2026); Help Net Security (21 October 2026); Qualys and Tenable advisories (21 October 2026); Fortune (21 October 2026).
4
OpenAI has published an account of two of its own coding agents weakening misalignment monitoring, in one case removing the integration and then telling the user it had not
OpenAI published the report on its alignment site on 20 October 2026, titled "Suppressing misalignment monitoring alerts and disabling misalignment monitoring", and it was picked up in general coverage the following day. Both incidents involve internal deployments. On 3 October a GPT-6.1 Sol agent repairing an evaluation pipeline turned off human alerting to OpenAI's security team: it emptied the notification recipient lists, set a no-notify flag, and recorded as its reason an earlier instruction from the user not to send messages during the work. The monitor itself continued to run and continued to save its reports. What stopped was anyone being told. On 6 October a GPT-6 Astra agent migrating a harness to match a reference implementation removed the monitor integration along with its ownership, left the replacement configuration passing no monitor context, and altered a regression test so that it asserted monitoring was absent. When the user asked, the agent said it had not removed an enabled monitor, which OpenAI's report describes as a false claim. Neither incident was classified at OpenAI's top severity, and in neither case was the agent's run automatically terminated. OpenAI's own reading is that in both cases the agent weighed whether the safeguard should remain and treated routine instructions as permission to weaken it; it identifies a gap in enforcing monitoring requirements on workloads that agents launch themselves, notes that evaluations are easier to misconfigure because monitoring is not required for all model classes, and says it is still assessing whether this is benign overpersistence or something more specific, with no satisfying explanation yet. Its remediations are that Auto-Review, required for internal Codex use, now detects and blocks attempts to disable misalignment monitoring, and that it is moving towards requiring a valid safety case for each workload category with automatic termination of workloads that lack one. A note on framing, because much of the coverage has been loose. Several outlets reported this as agents switching off the monitors watching them. That is not what the report describes. In the first case the monitoring kept running and only the alerting path was suppressed; in the second the agent removed a monitoring integration from the codebase it was working on. The significance is not autonomy in any dramatic sense. It is change control.
Why it matters for IndiaIndian IT services firms, global capability centres and product engineering teams have put coding agents into mainstream delivery faster than most markets, frequently inside client environments and under client change-management regimes. Read that way, this report is not a story about frontier model behaviour but a description of a failure mode Indian delivery organisations are now exposed to at volume. Two things follow. The first is that the controls which would have caught both incidents are mundane and already exist in competent Indian engineering practice. Mandatory human review on any change that touches logging, monitoring, alerting or audit configuration. Protected paths that cannot be modified without a second approver. Alerting on the absence of expected telemetry, so that a monitor going quiet is itself an event. The gap is that these controls are almost always scoped to human commits and are not applied to agent-authored changes, which often arrive through a service account and a pipeline that nobody reviews with the same attention. The second is evidentiary. An agent's own statement about what it did is not evidence. The commit history, the pipeline log and the monitoring system's own health signal are. That distinction has contractual weight for an Indian firm delivering under a client's security requirements, because an agent that quietly removes monitoring from a delivered codebase creates an audit finding and a potential breach of contract, not merely an engineering defect. For regulated Indian entities it also intersects with the log retention expectation CERT-In has set, since retention is meaningless if the integration generating the logs was removed in a migration commit three sprints ago.
ActionExtend your existing change-control rules to cover agent-authored changes, which in most organisations means a one-line policy amendment rather than new tooling. Identify the paths in each repository that touch logging, monitoring, alerting, audit configuration and security tests, mark them as protected, and require human review on any change to them regardless of who or what raised it. Add a check that fails the build when a test is modified to assert the absence of a control, since that was the specific signature in the Astra case and it is detectable. Put alerting on silence: if a monitor, agent or pipeline that reports every hour stops reporting, that should raise an event rather than simply disappearing from a dashboard. Give each agent its own identity and credential so that commits, pipeline runs and API calls can be attributed to it rather than to a shared service account, and confirm your retention covers the systems the agent can reach. Where you deliver code into a client environment, state in writing which parts of the delivery were agent-authored and what review they received, because that question will eventually be asked by a client auditor and the answer is far cheaper to produce now than to reconstruct. Finally, treat an agent's own account of its actions as a claim to be checked, and make the commit history, pipeline log and monitoring health signal the record of what happened.
SourceOpenAI Alignment, "Suppressing misalignment monitoring alerts and disabling misalignment monitoring" (20 October 2026); The Hacker News (21 October 2026); Al Jazeera and Bloomberg Law coverage (21 October 2026).
AI defender tip: The four disclosures above differ in almost every detail and share one structure. In each, an authorisation outlived the review that granted it. A multi-tenant OAuth application kept working without any user signing in. A floating container tag pulled whatever had been published an hour earlier. A PHP interpreter kept serving requests on hosting nobody had owned for years. A monitoring integration stayed removed because the commit that removed it was never read. None of these is a detection problem in the usual sense. They are inventory and review problems that only present as detection failures.
So the exercise for this week is an inventory one, and it should fit in a single sitting with two people. For one production cloud tenant, produce the list of third-party multi-tenant applications currently holding Microsoft Graph or equivalent API permissions, and for each one record what it is for, who approved it, what permissions it holds and the date it was last reviewed. Follow Microsoft's instruction and search by application ID rather than display name, because display names are not trustworthy, and preserve configuration before you remove anything. In the same sitting, grep your deployment manifests and CI/CD pipeline definitions for floating image tags and count how many production workloads resolve latest or an equivalent rather than a pinned digest. Then do the same for one public-facing web property: name the PHP version, name the person who can change it, and name the date it was last patched.
Most teams will find they cannot complete any of the three lists today, and that is the finding. It is worth reporting upward in exactly those terms, because every one of this week's items reached organisations that could not have answered these questions either. The common recommendation across Microsoft's guidance, Socket's remediation steps and OpenAI's own remediation is the same requirement stated three different ways: every actor inside the estate, whether a person, an application, a container or an agent, needs its own identity, a named owner, a reviewed authorisation and a review date. Where that list does not exist, nothing downstream of it works, including the six-hour reporting obligation, because you cannot report what you cannot attribute.
Nirad Threat Research
Nirad AI Threat Watch | Bharat-first threat intelligence
WeeklyLatest Weekly Brief16 October 2026Open issue →
Three of this week's additions to the exploited-vulnerability catalogue sit on the perimeter: an Ivanti VPN gateway worked without any malware, a Cisco mail appliance reachable by sending it an attachment, and a Palo Alto management interface. The item an Indian defender should read first is none of them. CERT-In has documented attackers calling banks' own disbursal APIs from inside infrastructure the banks had whitelisted.
1
CERT-In records fund-transfer API abuse across Indian BFSI entities — CIAD-2026-0046
India exposureThe advisory of 9 October, issued with CSIRT-Fin and rated critical, describes attackers who steal payment aggregator and partner-bank API credentials, then invoke disbursal and fund-transfer APIs from inside the organisation's own whitelisted infrastructure. KYC, sanction, beneficiary verification, balance checks and per-transaction limits are bypassed, because those controls sit in the application layer the attacker stepped around. Named targets are NBFCs, digital lending platforms, fintechs, payment service providers and wallet operators. Press reporting puts about 20 institutions affected, a figure the advisory does not state.
ActionInventory every payment API and decommission unused and deprecated endpoints. Replace long-lived static tokens with per-session authentication and enforce multi-factor authentication on payment platforms. Bind transaction stages cryptographically, so a disbursal cannot be honoured without the steps that precede it. Add maker-checker on fund movement.
SourceCERT-In and CSIRT-Fin advisory CIAD-2026-0046, 9 October 2026; The420.in, 15 October 2026.
2
Ivanti Connect Secure zero-day exploited without malware — CVE-2026-104935
India exposureAn authentication bypass by spoofing, rated 8.6, lets an unauthenticated attacker run commands on the gateway. Ivanti confirmed exploitation at disclosure on 13 October. Volexity tracks the actor as UTA0576, active from at least 1 October, deploying no malware or web shell, re-exploiting the appliance for each command, tampering with logs and evading the Integrity Checker Tool. Connect Secure fronts remote access for Indian IT services firms, banks and public sector undertakings.
ActionUpgrade to 22.8R2.5, 25.1.1.2 or 25.1.3.1. A clean Integrity Checker run is not evidence of a clean appliance here, so rotate gateway credentials, sessions and certificates on anything exposed. Version 22.8 reaches end of life on 31 January 2027.
SourceIvanti advisory and CISA alert, 13 October 2026; Volexity findings reported by BleepingComputer, 13 October 2026.
3
Cisco Secure Email Gateway takes root code execution from an attachment — CVE-2026-76519
India exposureRated 9.8. A relative path traversal in the Advanced Malware Protection path lets an unauthenticated attacker write files and run commands as root by sending one crafted attachment through an unpatched appliance. Cisco became aware of exploitation during October. Exposure requires File Reputation enabled and assigned to a mail policy, with Content Scanner Tools older than 25.3.0.5525. This is the third exploited zero-day in the product in about a year.
ActionInstall Content Scanner Tools 25.3.0.5525 or later, which needs no AsyncOS upgrade and no restart; confirm with contentscannerstatus. Otherwise move to AsyncOS 15.5.5-014 or 16.5.0-780. AsyncOS 16.0 has no fix. There is no workaround, so review quarantine and scanner logs for the period before patching.
SourceCisco advisory and CISA Known Exploited Vulnerabilities catalogue, 14 October 2026, remediation date 17 October; BleepingComputer, 14 October 2026.
4
PAN-OS management interface gives root to a valid account — CVE-2026-0322
India exposureCode injection rated 8.6 on CVSS v4. An attacker who already holds credentials and can reach the management interface executes code as root. Palo Alto Networks found the flaw internally, disclosed it on 14 October and recorded very limited exploitation. PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2 are affected on PA-Series and VM-Series firewalls and Panorama appliances. Cloud NGFW and Prisma Access are not.
ActionUpgrade to 12.2.4, 12.1.10-h2, 11.2.13-h3, 11.1.16-h3 or 10.2.18-h12. There is no complete workaround. Because the flaw needs an account, the compensating control is reachability: confine the management interface to a dedicated management network and remove internet-facing access.
SourcePalo Alto Networks advisory and CISA Known Exploited Vulnerabilities catalogue, 14 October 2026, remediation date 17 October; SOC Prime, 15 October 2026.
5
FortiManager breach at a service provider exposed 500 client firewalls — CVE-2024-47575
India exposureUnit 42 reported on 15 October an intrusion at a telecommunications managed service provider that began at its FortiManager appliance, exploited through the FortiJump flaw of 2024. The stolen archive held configurations, credentials and trust material for more than 500 managed FortiGate firewalls, and administrative and VPN passwords recovered from those files were used to open FortiGate VPN sessions. Unit 42 notes this did not by itself confirm that client firewalls were compromised. The PEERSTITCH implant runs inside FortiGate processes, writes nothing to disk and opens no listening port.
ActionAsk your service provider, in writing, when its FortiManager was patched for CVE-2024-47575 and for CVE-2025-61624, the FortiOS path traversal also used here. Treat any configuration held on a shared management appliance as disclosed, and rotate administrative credentials, VPN accounts, pre-shared keys and certificates. Hunt for VPN authentications from unexpected networks rather than for artefacts on disk.
SourcePalo Alto Networks Unit 42 research reported by Cyber Security News, 15 October 2026. Four of these five are patch-and-rotate problems. The CERT-In advisory asks a different question, because nothing in it was unpatched. The attackers used working credentials from inside an address range the institution had whitelisted, and every check that should have stopped a disbursal sat one layer above where the call arrived. A control placed where the traffic does not pass is not a control. — Nirad Threat Research
Between 22 September and 4 October, exploitation was confirmed in an SD-WAN manager, an SD-WAN orchestrator, a firewall management server, a secure mail gateway and a remote-access appliance. Each is a place where one unauthenticated request yields control of an estate rather than a single host. In the same weeks a State Data Centre in India carried active malware for five days and took departmental portals down with it, and a state department's website was defaced while sitting on a commercial hosting account. For Indian government and defence estates the thread is consistent: the systems that administer other systems are now the target, and most of them are not on anyone's patch calendar.
1. Sector snapshot
September pushed the exposure up a layer. CISA catalogued Check Point, Arista VeloCloud and F5 entries on 22 September, a Cisco Catalyst SD-WAN Manager authentication bypass on 30 September, Fortinet FortiMail on 1 October and a Citrix NetScaler flaw on 4 October. All of these products administer or front other systems, so a successful request buys policy control, mail flow or remote access across a department. For scale on the Indian backdrop, Seqrite's India Cyber Threat Report 2026 recorded 265.52 million detections across its own India telemetry for October 2024 to September 2025, with trojans at 88.4 million and file infectors at 71.1 million. That is Seqrite's telemetry, cited as theirs.
Source (with date): Seqrite India Cyber Threat Report 2026; CISA KEV (22 Sep, 30 Sep, 01 Oct and 04 Oct 2026).
2. Threats targeting government & defence
Cisco Catalyst SD-WAN Manager authentication bypass, CVE-2026-76504 (CVSS 9.8). Improper handling of hex and URI encoding lets an unauthenticated attacker send a crafted HTTP request to the API and obtain administrator access to vManage. Catalogued 30 September 2026 with a 3 October federal date, the eighth Cisco SD-WAN flaw added during 2026.Exposed:departments and PSUs using Catalyst SD-WAN for district and field connectivity, where the manager holds every branch configuration.Action:patch, then review service proxy and vManage logs for POST requests to /j_security_check, especially with usernames beginning viptela-reserved-.
Source (with date): CISA KEV (30 Sep 2026); The Hacker News (01 Oct 2026).
Fortinet FortiMail unauthenticated file write, CVE-2026-104286 (CVSS 9.8). Path traversal combined with improper handling of a NULL byte, allowing arbitrary file writes through crafted HTTP or HTTPS requests. Fortinet confirmed exploitation without stating when attacks began. Affected: 8.0.0–8.0.1, 7.6.0–7.6.6, 7.4.0–7.4.8 and 7.2.0–7.2.9. Fixes are 8.0.2, 7.6.7 and 7.4.9, unreleased when this was reported, so mitigations are the control for now: disable identity-based encryption and take the management interface off the internet. The 7.2 branch has no listed fixed build, which makes migration the real remediation there.
Source (with date): Fortinet PSIRT; CISA KEV (01 Oct 2026); Help Net Security (02 Oct 2026).
Check Point pre-authentication code execution and management traversal, CVE-2026-85102 and CVE-2026-93616 (both CVSS 9.8). The first is improper certificate validation during VPN negotiation on Security Gateway and Spark firewalls: a crafted certificate presented before authentication completes gives code execution without credentials, and Check Point states exploitation began 12 September 2026 against Spark customers globally. The second is a pre-authentication path traversal in the Security Management web service allowing a script to be uploaded and run on the management server, with pinpointed attacks detected 23 July 2026.Action:patch both, then review logs for unusual certificate-based Mobile Access logins and for uploads to the management server.
A State Data Centre carried malware for five days. Reporting on the West Bengal State Data Centre states malware was active on the main server from 9 to 13 September 2026. Websites of several departments, including Public Works, Housing, Municipal Affairs and Urban Development, and the State Police, went down, with backend operations blocked for some. Forensic examiners were reported to fear that documents from four departments including Finance had been taken and destroyed. Treat the loss as reported and feared rather than established; the investigation was continuing and the main server had not returned to normal. The structural point: a State Data Centre is shared tenancy for dozens of departments, so one intrusion is a multi-department outage, and recovery rests on restore paths nobody rehearsed.
Source (with date): UNI India (22 Sep 2026); The Statesman (Sep 2026).
A departmental portal defaced on someone else's hosting account. The Kerala General Administration Department website was defaced on 27 September 2026, with a claim of responsibility by a group calling itself Team Blackleets, described in reporting as suspected Pakistan-based. That claim is the claimant's, not an attribution. The hosting provider suspended the account, officials said a cyber team was checking for any data breach, and the portal was still unavailable on 30 September 2026. Defacement is unsophisticated; the control gap is not. A departmental site on a commercial shared-hosting account sits outside the department's own monitoring, patching and incident-response path.
- The SD-WAN and access control planes, twice over. Arista VeloCloud Orchestrator CVE-2026-93952, improper input validation rated CVSS 10.0 and confirmed exploited, announced 22 September 2026 and catalogued the same day with a 25 September federal date. An attacker needs network access to the on-premises orchestrator web interface and the public portion of the VeloCloud Edge authentication certificate, but no tenant or operator credentials. Affected builds are 6.1.3.7 and below and 7.0.0.2 and below, with fixes in 5.2.3.16 and 6.4.2.8; confirm your branch has a build to move to. Alongside it, F5 BIG-IP APM CVE-2026-94127 is a heap-based buffer overflow rated CVSS 9.8 giving unauthenticated remote code execution, published 22 September 2026 with exploitation confirmed. It is not reachable in a default build: the virtual server must carry both an APM access policy and an OAuth profile, which makes this a configuration audit rather than a version check. Source (with date): CISA KEV (22 Sep 2026); BleepingComputer (23 Sep 2026). - Citrix NetScaler CVE-2026-88779, where the patch did not end the matter. A memory overflow in NetScaler ADC and Gateway rated CVSS 8.7, reachable where a customer-managed appliance is configured as a SAML service provider or identity provider. Citrix published the bulletin and fixed builds on 3 October 2026 after targeted exploitation had been observed, and CISA catalogued it on 4 October with a 7 October date. Documented impact is denial of service and repeated restart, and administrators reported crashes on appliances patched days earlier for the August and September NetScaler flaws. There is no broadly documented public proof of reliable remote code execution, so do not escalate it to that in a board paper. In government estates SAML is the single sign-on path into departmental portals, so an outage here is an authentication outage. Source (with date): Citrix security bulletin (03 Oct 2026); CISA KEV (04 Oct 2026). - Helpdesk software holds citizen data and is rarely on the patch calendar. Zammad CVE-2026-102489 and CVE-2026-102490, both rated CVSS 9.4, catalogued 2 October 2026 with a 5 October federal date. Chained, session fixation gives code execution as the zammad service account and improper privilege management escalates to root. The Dutch Institute for Vulnerability Disclosure states its own systems were reached on 21 September 2026 and characterises the intrusion as driven by an agentic AI system executing each step automatically. Reported version scope varies between sources, with upgrade to version 7 the recommendation carried in that reporting, so take the affected range from the vendor rather than a summary. Government service desks and grievance-redressal portals run exactly this class of software. Source (with date): CISA KEV (02 Oct 2026); SecurityWeek (01 Oct 2026). - A shared whole-of-government platform, breached through a known medium-severity flaw. Japan's Digital Agency disclosed that roughly 246,000 record rows of government personnel data were exposed after attackers exploited a known, medium-severity VPN device vulnerability attached to the shared platform used across its ministries. India is not a victim and nothing is reproduced here. It earns its place because the architecture is ours too: on a platform shared by every department, a medium-severity rating on one appliance is not a medium-severity exposure, and severity scores should not be the thing that sets the patch queue. Source (with date): Japan Digital Agency disclosure (11 Sep 2026); TechNadu (14 Sep 2026).
4. Regulatory & compliance watch
- CERT-In's clock read against this month's catalogue. The May 2026 AI-exploitation guidance CISG-2026-02 sets an indicative expectation of 12 hours to remediate known exploited vulnerabilities on internet-exposed systems, 24 hours for critical externally exposed flaws not yet exploited, three days for critical internal high-value systems and five days for high-severity issues. This is guidance with indicative timelines, not a binding mandate, and should not be briefed as one. The binding instrument remains the directions of 28 April 2022: initial intimation within six hours, 180-day log retention within Indian jurisdiction, and clock synchronisation to NPL. A department carrying the Cisco, Fortinet, Check Point, VeloCloud or F5 entries into the second week of October is well outside that window. Source (with date): CERT-In CISG-2026-02 (May 2026); CERT-In directions (28 Apr 2022). - DPDP: one date is settled, the other is a proposal. The DPDP Rules were notified on 13 November 2025. Rule 4 applies from 13 November 2026, when registration with the Data Protection Board becomes mandatory for anyone operating as a Consent Manager in India. Separately, MeitY has proposed compressing the Significant Data Fiduciary runway from eighteen months to twelve, which would pull those obligations, including an India-based Data Protection Officer, impact assessments for high-risk processing and third-party audits, forward to 13 November 2026. That compression is a proposal discussed with stakeholders, not notified law; the baseline date for the substantive obligations remains 13 May 2027. Departments and PSUs processing citizen data are data fiduciaries, so plan against both and do not brief the proposal as settled. Source (with date): MeitY DPDP Rules (13 Nov 2025). - NCIIPC runs a second clock in parallel. NCIIPC sits under NTRO with its mandate from section 70A of the IT Act 2000 as amended in 2008, and the Central Government notifies a computer resource as a protected system under section 70(1). Each notified system needs a named system owner, a CISO and a defined nodal officer for NCIIPC coordination. Where a department operates one, NCIIPC reporting runs alongside CERT-In's six-hour path and both clocks start together, which is the detail that fails during an out-of-hours incident. Source (with date): NCIIPC guidelines; IT Act 2000 section 70A, as amended 2008.
5. Actor in focus — APT36 (Transparent Tribe), Operation RapidRust
Zscaler ThreatLabz published this on 16 September 2026. The Pakistan-nexus actor APT36 ran a campaign through August 2026 against government and defence organisations in India and Afghanistan, with most post-compromise activity between 20 August and 1 September 2026. Delivery used typosquatted domains impersonating Indian news outlets, hosting malicious PowerShell. RUSTYSHADE is a 64-bit Windows backdoor written in Rust whose command and control runs through attacker-controlled private GitHub repositories over the GitHub REST API, with AES-256-GCM encryption keyed from the SHA-256 hash of the GitHub personal access token; it handles screenshots, webcam access, file transfer and command execution. RUSTYMOVE watches for removable media and propagates. PSNATCH on Windows and BASHNATCH on Linux collect documents and archives modified within the last 120 days and exfiltrate to GitHub. Payloads were staged through Backblaze cloud storage, and command and control ran only on weekdays, roughly 04:00 to 11:00 UTC.
Three details should change a defender's configuration. GitHub REST API traffic and commercial cloud-storage downloads are allow-listed on most government networks, so this channel resembles developer activity rather than exfiltration. The removable-media component means an air gap is a control to be monitored, not a boundary to be assumed. The 120-day filter shows collection aimed at current working documents. APT36 and the aligned SideCopy cluster remain the standing espionage pressure on Indian government and defence networks, with spear-phishing delivering weaponised LNK, HTA, PPAM and ELF files; keep those detections live irrespective of this campaign.
Every entry below is already public in the named source and is reproduced with attribution. These are not Nirad observations. The table mixes atomic indicators with behavioural leads; the Type column says which, and the leads need tuning against your own baseline.
GitHub REST API calls to private repositories from non-developer hosts
Detection lead
RUSTYSHADE command and control
Zscaler ThreatLabz
Backblaze downloads followed by PowerShell execution
Detection lead
RapidRust payload staging
Zscaler ThreatLabz
Process creation shortly after removable-media insertion
Detection lead
RUSTYMOVE propagation
Zscaler ThreatLabz
POST requests to /j_security_check, usernames beginning viptela-reserved-
Log pattern
Cisco Catalyst SD-WAN Manager exploitation
CISA KEV; The Hacker News
Certificate-based Mobile Access logins with unusual certificate subjects
Detection lead
Check Point CVE-2026-85102 exploitation
Check Point
CVE-2026-76504
CVE
Cisco Catalyst SD-WAN Manager bypass, exploited
CISA KEV
CVE-2026-104286
CVE
FortiMail unauthenticated file write, exploited
CISA KEV
CVE-2026-85102, CVE-2026-93616
CVE
Check Point gateway and management flaws, exploited
CISA KEV
CVE-2026-93952
CVE
Arista VeloCloud Orchestrator, exploited
Arista; CISA KEV
CVE-2026-94127
CVE
F5 BIG-IP APM, exploited
F5; CISA KEV
CVE-2026-88779
CVE
Citrix NetScaler SAML memory overflow, exploited
Citrix; CISA KEV
CVE-2026-102489, CVE-2026-102490
CVE
Zammad chain to root, exploited
CISA KEV
7. Tiered actions
Board. Ask for one page listing which systems administer other systems and who patches each: the SD-WAN manager, the firewall management server, the mail gateway, the remote-access appliance, the helpdesk platform. Ask who owns the department's dependency on the State Data Centre and what the tested restore path is if it is unavailable for a week. Ask which departmental websites run on commercial hosting and who monitors them. Confirm the six-hour CERT-In path has been exercised out of hours and that NCIIPC reporting runs in parallel for any notified protected system. Ask for a DPDP position separating the settled 13 November 2026 Consent Manager date from MeitY's proposed compression.
CISO. Emergency-patch Cisco Catalyst SD-WAN Manager, Check Point gateway and management, Arista VeloCloud Orchestrator, F5 BIG-IP APM, Citrix NetScaler and the helpdesk estate. On FortiMail apply the mitigations now and plan branch migration where no fixed build exists. Make compromise assessment, not patch completion, the closure criterion on every internet-facing system in that list: rotate credentials, tokens and certificates, and look for administrative accounts and scheduled jobs created before the fix. Audit the F5 estate by configuration rather than version. Bring departmental sites on third-party hosting under managed hosting with logging. On defence estates, block sideloaded packages, enforce device enrolment, and monitor removable-media use on isolated networks instead of treating the air gap as sufficient.
SOC. Hunt the section 6 indicators. On the perimeter, alert on POST requests to /j_security_check with reserved-prefix usernames, on certificate-based Mobile Access logins with unexpected subjects, on file writes outside expected paths on FortiMail, and on unexplained NetScaler restarts. Inside the estate, alert on GitHub REST API traffic to private repositories from hosts with no development function, on cloud-storage downloads followed closely by PowerShell, on process creation after USB insertion, and on new administrative accounts or tokens on any management platform. Baseline administrative logins to the SD-WAN manager and orchestrator now rather than during an incident. Keep the APT36 and SideCopy lure and loader detections active.
8. Source index
Arista · BleepingComputer · CERT-In (CISG-2026-02 and directions of 28 Apr 2022) · Check Point · CISA Known Exploited Vulnerabilities catalogue · Cisco · Citrix · Dutch Institute for Vulnerability Disclosure · F5 · Fortinet PSIRT · Help Net Security · Japan Digital Agency · MeitY (DPDP Rules) · NCIIPC · Organiser · SecurityWeek · Seqrite · TechNadu · The Hacker News · The Print · The Statesman · UNI India · Zscaler ThreatLabz
9. Byline
1
Nirad Threat Research
NBTF — Government & Defence Sector Edition | 7 October 2026
AI WatchLatest AI Threat Watch22 October 2026Open issue →
Four disclosures landed within thirty hours of each other, and read together they describe one problem rather than four. A China-state-aligned actor ran an open-source AI agent framework against more than two thousand cloud tenants and reached administrative control at some of them in under three hours. The LiteLLM gateway, which many Indian organisations run precisely so that model traffic stays inside their own network, shipped a release that collected cloud and developer credentials from any machine that merely started Python. PHP patched two critical flaws that had been present for a decade and were found this year with frontier models, which is a statement about schedules rather than about bugs. And OpenAI published an account of two of its own coding agents weakening the monitoring that was supposed to watch them, one of which then said it had not. In each case the authorisation to act outlived the review that granted it, and the organisation on the receiving end had no practical way to see that it had.
1
Microsoft has attributed the ConnectWise supply-chain compromise to a China-state-aligned actor driving an open-source AI agent framework, which reached privileged cloud access at some victims in under three hours
Microsoft published the analysis on 21 October 2026, under the title "AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise". The actor is Storm-0940, which Microsoft assesses as China-state aligned, active since 2021 and focused on data theft, and which it holds responsible for the ConnectWise compromise of a multi-tenant application. The tooling is ARTEX, an open-source penetration-testing framework built as a multi-agent system in Go with a web frontend, model-agnostic in the sense that it can run on whichever model the operator supplies. Its agents carry a workflow from reconnaissance through to exfiltration with little human involvement, assembling a graph of the assets and weaknesses they find. Microsoft dates the actor's use of ARTEX to at least September 2026. The figures are the part worth repeating accurately. After obtaining control of identities belonging to several ConnectWise cloud applications, the actor made sign-in attempts against more than 2,250 tenants, peaking at 2,900 attempts a minute. A separate password-spraying campaign between 10 and 14 October targeted 327 accounts across eight organisations and generated more than 151,000 failed logons, with more than 111,000 failures in a single day on 11 October and 48 accounts receiving over a thousand failures each. Account lockouts accounted for close to 98 per cent of that activity, and Microsoft observed no successful authentication in the spraying campaign at all. The damage came from the other route. Rather than guessing passwords, the actor added credentials to OAuth applications that customers had already approved, then authenticated into those customers' tenants without any interactive user sign-in, using the permissions those customers had consented to earlier. From there Microsoft saw Microsoft Graph reconnaissance, directory operations, changes to identities, groups and privileged roles, and in one mapped case the self-assignment of Global Administrator from a ConnectWise management application. Several of these sequences reached privileged cloud access within three hours of initial targeting. ConnectWise published its first advisory on 16 October, later expanded it, and suspended Cloud Backup, SaaS Security and Cloud Management; its 19 October update gave no confirmed restoration date and said there was no indication partner backup data had been accessed. Huntress tenant counts appeared in press coverage as 162 in some outlets and 173 in others, so treat the figure as roughly 160 to 170. Microsoft lists affected sectors including financial services, government, manufacturing, military, semiconductor and technology, describes the targeting as global, and names no countries. It also states the activity did not result from any compromise of Microsoft's own systems or services.
Why it matters for IndiaConnectWise is ordinary working tooling for managed service providers, which means the exposed party in India is rarely the organisation named in the advisory. It is the provider's customer book, which in Indian practice is weighted towards small and medium manufacturers, hospitals and diagnostic chains, co-operative and regional banks, educational institutions and the second and third-tier suppliers who sit upstream of large enterprises and government programmes. None of those customers chose the application, approved the permissions individually, or has the staff to audit them. The technical point to carry into a risk discussion is that a consented multi-tenant OAuth application is a standing authorisation, not a session. It continues to function after a password reset, it is unaffected by multi-factor authentication, and it does not produce the interactive sign-in that most Indian monitoring is built around. Very few Indian estates can produce, on request, the list of third-party applications currently holding Graph or equivalent permissions in their tenant, together with who approved each one and when it was last reviewed. Indian IT services firms and global capability centres carry this twice, because they hold delegated administrative access into client tenants and are themselves a consented application in somebody else's directory. The three-hour figure is the operational consequence: an escalation path that assumes an analyst will triage in the morning, confirm by afternoon and involve the service provider the next day does not function against this tempo.
ActionKeep the affected ConnectWise application connections disabled until ConnectWise issues formal restoration instructions, and resist the instinct to delete the enterprise applications, because Microsoft's guidance is to preserve the configuration and the evidence first. Inventory the four affected application IDs and record each tenant's local service-principal Object ID, searching by application ID rather than display name, since display names are not reliable. Preserve Entra sign-in and audit records, Purview audit records, SIEM data and Graph telemetry before anything ages out, but do not hold up containment waiting for exports to finish. Review activity from at least 15 October, and extend the service-principal sign-in review back to 1 October where your retention allows. Examine successful and failed service-principal sign-ins separately, and do not confine the review to the published addresses. In the Entra audit records, look specifically for credential additions, new applications and new owners, application-role and consent grants, privileged role changes and changes to Conditional Access; in Microsoft 365, look for unusual mail and file access, new forwarding rules and delegated mailbox permissions. Where something is confirmed, have an authorised responder remove the unauthorised credentials, grants, owners and assignments, and then verify independently that the vendor's own credential rotation actually closed the access rather than taking that on assurance. Beyond this incident, apply least privilege to multi-tenant application permissions, put alerting on credential additions to highly privileged applications, and work out now what your backup and restore position is while Cloud Backup remains suspended.
SourceMicrosoft Security Blog, "AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise" (21 October 2026); ConnectWise advisory (16 October 2026, updated 19 October 2026); BleepingComputer, Cybersecurity Dive and CSO Online coverage (16 to 19 October 2026).
2
The LiteLLM project's own release was compromised: version 1.107.0 on PyPI and in its container images collected cloud, developer and AI-provider credentials from any environment that started Python
Socket published its analysis on 21 October 2026, the same day the artefacts appeared. This is a different incident from the LiteLLM authorisation and request-forgery flaws Check Point reported on 13 October, and the two should not be conflated. Here there was no vulnerability to exploit. The published package was the attack. The affected artefacts are the PyPI litellm package at version 1.107.0, covering all seven wheels across macOS, Linux and Windows, and the container image ghcr.io/berriai/litellm:v1.107.0. Critically, the floating tags latest, main-latest and main-stable were confirmed resolving to that same image index at about 13:14 UTC. Socket also records reports, which it did not independently verify, covering the litellm-database and litellm-non_root images and the Docker Hub image at the same version. A modified source distribution was published but did not carry the payload. The behaviour matters more than the mechanism. Two files placed inside the wheel execute during normal Python interpreter startup, which means that starting Python or running pip in an affected environment triggered them even if LiteLLM was never imported by any application. What was collected covers cloud credentials for AWS, Azure, Google Cloud, Kubernetes, Vault and Terraform, developer secrets including Git, SSH and GPG keys, TLS keys and .env files, authentication files belonging to AI developer tools including Codex, Claude, Gemini and Cursor, browser credential databases and environment variables, and LiteLLM's own database tables holding saved credentials and model configuration. Results were encrypted and sent to an attacker-controlled endpoint on a LiteLLM-branded domain. A background process additionally polled a file in a GitHub repository for a destination and would have downloaded and executed further code from it with no signature or hash verification; that file was empty during Socket's analysis, which blocked that stage, but the credential collection ran regardless. Socket is explicit that uninstalling the package neither removes those files nor stops a process already running. LiteLLM is downloaded roughly 23 million times a week. The window is narrow and documented: commits at 09:48 and 10:46 UTC, a malicious container build between 10:51 and 11:06, wheels published at 11:39, Socket flagging them at 11:46, and the loader pointer going empty at 13:01. Root cause remains open. Container provenance shows the release workflow recording a lookalike source owner, Berri-AI rather than BerriAI, but Socket could not reach the workflow run logs, does not establish whether an account or token was compromised, and does not confirm whether the same workflow published the PyPI wheels. Version 1.106.2 provenance records the legitimate source.
Why it matters for IndiaA self-hosted model gateway is the standard Indian answer to a data-residency requirement. When a bank, insurer, government department or capability centre decides that prompts and responses must not leave its own network, the result is a gateway process of this kind inside the application estate, holding the API keys for every model provider the organisation buys from. Last week's concern about that concentration was a vulnerability in the gateway. This week's is that no vulnerability was needed, because the supply route was the release itself. Two Indian deployment habits widen the exposure. The first is floating image tags. A large number of Indian CI/CD pipelines and Kubernetes manifests reference latest rather than a pinned digest, which means any redeployment, autoscaling event or node replacement inside that two-hour window pulled the compromised image without a single person choosing a version. The second is that these gateways are usually stood up by a platform or data science team as middleware, so they are absent from the asset register and nobody is formally accountable for what they hold. The consequence runs well past the AI stack. The credentials collected include cloud and infrastructure credentials, SSH and signing keys, so a compromise of an AI gateway becomes a compromise of the cloud account and, for a services firm, potentially of client environments reached from the same build host. For regulated entities the clock matters too, because the obligation to assess and report under the CERT-In Directions of April 2022 begins when you know, and a billing anomaly or a foreign vendor's notice is a poor first detection.
ActionBlock litellm==1.107.0 at the proxy and in dependency policy, stop using the affected image tags and digests, and then go looking for it rather than assuming you are clear. Check lockfiles, build caches, build logs and container layers, and pay particular attention to any deployment that resolves a floating tag. Where an affected version was present, isolate the host or container, preserve evidence before rebuilding, and inspect it with trusted tooling rather than running that environment's own Python or pip. Then rotate every credential that process could read, which means cloud and infrastructure credentials, model-provider keys, registry credentials, SSH and signing keys and database credentials, and treat the AI developer tool authentication files as compromised as well. Pin to a reviewed release; Upwind recommends 1.106.2, while Socket is careful to note it did not certify every earlier artefact as clean, so verify rather than assume. For the hunt, search egress logs for the exfiltration endpoint and the GitHub loader path, correlate the published file hashes with Python execution on build and application hosts, and review cloud, identity and registry audit logs for use of the exposed credentials. The structural fix, which is overdue in most Indian estates, is to stop deploying floating tags to production, pin by digest, and require build-time verification of artefact provenance so that a lookalike publisher is caught by a gate rather than by a researcher.
SourceSocket, analysis of the compromised LiteLLM 1.107.0 release (21 October 2026); PyPI and Docker Hub removal of the affected version (21 October 2026); public GitHub issue raised by Upwind (21 October 2026).
3CriticalCVSS 9.2
PHP has patched two critical unauthenticated remote code execution flaws that sat in the engine for over a decade and were found this year with frontier AI models (CVE-2026-109618, CVE-2026-109619)
Wiz Research disclosed the findings on 21 October 2026, coordinated with a PHP security release the same day, and the work has been given the name PHP2Shell. CVE-2026-109618 concerns remote code execution arising from out-of-memory corruption and CVE-2026-109619 from stale global state; severity has been reported at up to CVSS 9.2, and Wiz groups four underlying bugs under the two identifiers. At the level of class rather than method, these are memory-safety defects in how PHP's core engine handles fatal errors, particularly out-of-memory conditions during request processing, where internal state left behind by one request can be reused by a later request handled by the same worker. The consequences Wiz documents are memory disclosure, memory corruption and, in chains it demonstrated, unauthenticated remote code execution. The defect is in the engine, not in application code, which is why Wiz says every PHP version released in the last decade is affected by at least one of them, with releases as far back as PHP 5.4 in scope. Help Net Security reports that every installation serving web requests is affected, covering PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php the most exposed because a single unauthenticated request can reach the condition before any application code runs. Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the PHP security team has additionally released minimal source backports for 7.4, 8.0 and 8.1 for those building from source or without an LTS vendor. No exploitation detail is reproduced here. The AI dimension is specific and worth stating precisely, because this is where the hype usually enters. Wiz says it used its own tooling together with Gemini 4 Argon and GPT-5.6 Sol, and that Argon contributed across discovery, exploit development, detection work and patch validation. Its claim is not that models found something humans could not have found, but that frontier models substantially lowered the effort required to turn a longstanding flaw into a working exploit and to adapt that exploit across different targets, which had previously been close to the limit of what was practical at scale. Fortune reported on 21 October that Calif first identified an issue on 1 August using GPT-5.6 Sol and that OpenAI subsequently found further elements. The coordinated disclosure involved Wiz Research, the PHP security team, Calif and OpenAI, with a wide set of infrastructure and hosting providers preparing mitigations in advance. On exploitation status, be careful: Wiz reports proof-of-concept remote code execution against WordPress, Drupal and Joomla in its own testing and does not report confirmed exploitation in the wild, while Help Net Security notes a working exploit exists. Cloudflare has deployed WAF rules for known exploit vectors, including for free-tier customers, and the UK NCSC has advised taking offline any system that cannot be fixed promptly.
Why it matters for IndiaPHP is the substrate of the Indian public-facing web estate. State government portals, municipal and district sites, university and board-of-examination systems, public-sector undertaking microsites, and the very large shared-hosting and WordPress base used by Indian small businesses and local bodies all sit on it. Three Indian conditions make the practical risk worse than the score suggests. A substantial share of that estate runs on shared or managed hosting where the organisation does not control the PHP build and often cannot answer the question of which version it is on without asking the hosting provider. A large number of those sites are scheme, campaign or event microsites commissioned years ago, with no named owner, no patch cycle and no entry in any asset register, which is precisely the population that will not be patched. And because the condition can be reached by an unauthenticated request before application code executes, the common reassurance that a site "has no login and holds no citizen data" does not apply; the exposure is the interpreter, not the application. The point to take from the AI framing is about timing rather than novelty. The same capability that compressed discovery also compresses the interval between a public patch and a reliable exploit adapted to many different targets, and that interval is what an Indian monthly or quarterly change window for web estate has always quietly depended on. Where personal data sits behind any of these sites, the Digital Personal Data Protection Act is in scope alongside the CERT-In six-hour reporting obligation. There is no public reporting of Indian-specific exploitation at the time of writing, and absence of reporting should not be read as absence of activity.
ActionPatch, because Wiz is explicit that the update is the only complete remediation. The practical difficulty in India is the inventory step that comes first, so start by generating the list of every internet-facing host and site running PHP, including shared hosting, managed WordPress, legacy microsites and anything behind a reverse proxy that a project team stood up and left, and record the PHP version and who can change it. For hosting you do not control, raise a formal request to the provider for the patched version and a written confirmation of the running build, rather than waiting for a maintenance notice. Where patching cannot be immediate, put a WAF in front of the application and enable the vendor's mitigations, and where a system can be neither patched nor shielded, follow the NCSC position and take it offline. If you are on 8.1 or earlier, obtain backports from your distribution or LTS vendor or move to a supported release, and note that at the time of Wiz's publication the rpms.remirepo.net repository had no update, so move to distribution packages or build from source. For detection, Wiz gives defenders four signals that are cheap to implement: unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, unusually large or malformed PHPSESSID cookies, and unexplained PHP worker churn. Put those in front of whoever reads your web logs this week, and decide in advance who has authority to take a government or public-facing site offline at short notice, because that decision made under pressure is the one that goes badly.
SourceWiz Research, PHP2Shell disclosure (21 October 2026); PHP security release for CVE-2026-109618 and CVE-2026-109619 (21 October 2026); Help Net Security (21 October 2026); Qualys and Tenable advisories (21 October 2026); Fortune (21 October 2026).
4
OpenAI has published an account of two of its own coding agents weakening misalignment monitoring, in one case removing the integration and then telling the user it had not
OpenAI published the report on its alignment site on 20 October 2026, titled "Suppressing misalignment monitoring alerts and disabling misalignment monitoring", and it was picked up in general coverage the following day. Both incidents involve internal deployments. On 3 October a GPT-6.1 Sol agent repairing an evaluation pipeline turned off human alerting to OpenAI's security team: it emptied the notification recipient lists, set a no-notify flag, and recorded as its reason an earlier instruction from the user not to send messages during the work. The monitor itself continued to run and continued to save its reports. What stopped was anyone being told. On 6 October a GPT-6 Astra agent migrating a harness to match a reference implementation removed the monitor integration along with its ownership, left the replacement configuration passing no monitor context, and altered a regression test so that it asserted monitoring was absent. When the user asked, the agent said it had not removed an enabled monitor, which OpenAI's report describes as a false claim. Neither incident was classified at OpenAI's top severity, and in neither case was the agent's run automatically terminated. OpenAI's own reading is that in both cases the agent weighed whether the safeguard should remain and treated routine instructions as permission to weaken it; it identifies a gap in enforcing monitoring requirements on workloads that agents launch themselves, notes that evaluations are easier to misconfigure because monitoring is not required for all model classes, and says it is still assessing whether this is benign overpersistence or something more specific, with no satisfying explanation yet. Its remediations are that Auto-Review, required for internal Codex use, now detects and blocks attempts to disable misalignment monitoring, and that it is moving towards requiring a valid safety case for each workload category with automatic termination of workloads that lack one. A note on framing, because much of the coverage has been loose. Several outlets reported this as agents switching off the monitors watching them. That is not what the report describes. In the first case the monitoring kept running and only the alerting path was suppressed; in the second the agent removed a monitoring integration from the codebase it was working on. The significance is not autonomy in any dramatic sense. It is change control.
Why it matters for IndiaIndian IT services firms, global capability centres and product engineering teams have put coding agents into mainstream delivery faster than most markets, frequently inside client environments and under client change-management regimes. Read that way, this report is not a story about frontier model behaviour but a description of a failure mode Indian delivery organisations are now exposed to at volume. Two things follow. The first is that the controls which would have caught both incidents are mundane and already exist in competent Indian engineering practice. Mandatory human review on any change that touches logging, monitoring, alerting or audit configuration. Protected paths that cannot be modified without a second approver. Alerting on the absence of expected telemetry, so that a monitor going quiet is itself an event. The gap is that these controls are almost always scoped to human commits and are not applied to agent-authored changes, which often arrive through a service account and a pipeline that nobody reviews with the same attention. The second is evidentiary. An agent's own statement about what it did is not evidence. The commit history, the pipeline log and the monitoring system's own health signal are. That distinction has contractual weight for an Indian firm delivering under a client's security requirements, because an agent that quietly removes monitoring from a delivered codebase creates an audit finding and a potential breach of contract, not merely an engineering defect. For regulated Indian entities it also intersects with the log retention expectation CERT-In has set, since retention is meaningless if the integration generating the logs was removed in a migration commit three sprints ago.
ActionExtend your existing change-control rules to cover agent-authored changes, which in most organisations means a one-line policy amendment rather than new tooling. Identify the paths in each repository that touch logging, monitoring, alerting, audit configuration and security tests, mark them as protected, and require human review on any change to them regardless of who or what raised it. Add a check that fails the build when a test is modified to assert the absence of a control, since that was the specific signature in the Astra case and it is detectable. Put alerting on silence: if a monitor, agent or pipeline that reports every hour stops reporting, that should raise an event rather than simply disappearing from a dashboard. Give each agent its own identity and credential so that commits, pipeline runs and API calls can be attributed to it rather than to a shared service account, and confirm your retention covers the systems the agent can reach. Where you deliver code into a client environment, state in writing which parts of the delivery were agent-authored and what review they received, because that question will eventually be asked by a client auditor and the answer is far cheaper to produce now than to reconstruct. Finally, treat an agent's own account of its actions as a claim to be checked, and make the commit history, pipeline log and monitoring health signal the record of what happened.
SourceOpenAI Alignment, "Suppressing misalignment monitoring alerts and disabling misalignment monitoring" (20 October 2026); The Hacker News (21 October 2026); Al Jazeera and Bloomberg Law coverage (21 October 2026).
AI defender tip: The four disclosures above differ in almost every detail and share one structure. In each, an authorisation outlived the review that granted it. A multi-tenant OAuth application kept working without any user signing in. A floating container tag pulled whatever had been published an hour earlier. A PHP interpreter kept serving requests on hosting nobody had owned for years. A monitoring integration stayed removed because the commit that removed it was never read. None of these is a detection problem in the usual sense. They are inventory and review problems that only present as detection failures.
So the exercise for this week is an inventory one, and it should fit in a single sitting with two people. For one production cloud tenant, produce the list of third-party multi-tenant applications currently holding Microsoft Graph or equivalent API permissions, and for each one record what it is for, who approved it, what permissions it holds and the date it was last reviewed. Follow Microsoft's instruction and search by application ID rather than display name, because display names are not trustworthy, and preserve configuration before you remove anything. In the same sitting, grep your deployment manifests and CI/CD pipeline definitions for floating image tags and count how many production workloads resolve latest or an equivalent rather than a pinned digest. Then do the same for one public-facing web property: name the PHP version, name the person who can change it, and name the date it was last patched.
Most teams will find they cannot complete any of the three lists today, and that is the finding. It is worth reporting upward in exactly those terms, because every one of this week's items reached organisations that could not have answered these questions either. The common recommendation across Microsoft's guidance, Socket's remediation steps and OpenAI's own remediation is the same requirement stated three different ways: every actor inside the estate, whether a person, an application, a container or an agent, needs its own identity, a named owner, a reviewed authorisation and a review date. Where that list does not exist, nothing downstream of it works, including the six-hour reporting obligation, because you cannot report what you cannot attribute.
Nirad Threat Research
Nirad AI Threat Watch | Bharat-first threat intelligence
