Bharat Threat FeedGlobal threats, decoded for Indian defenders
AI Threat Watch · 17 September 2026

AI Threat Watch — 17 September 2026

Seven critical flaws landed in agent-orchestration and inference software on a single day this week, and the pattern in them is not sophistication. It is that the authentication was available in the product and was never invoked. Mandiant and Google's threat intelligence team published a report on the same theme from the other end, including a case in which an agent's own runaway loop cost an organisation about fifty thousand dollars in an hour without any attacker involved. Australia's cyber agency issued guidance that moves the security question off the model and onto the software layer around it, which is the layer an Indian organisation actually builds and owns. And Tamil Nadu's cyber crime branch made an arrest over a cloned-voice video of the Chief Minister used to take money from people in several states, which is the version of this technology that reaches ordinary citizens first.
1

Seven critical flaws in agent and inference software were published on 14 September, and in most of them the authentication controls existed in the product but were never switched on

Five issues rated 9.8 were published against MervinPraison PraisonAI and its companion package praisonaiagents on 14 September 2026: CVE-2026-57123, CVE-2026-57124, CVE-2026-57125, CVE-2026-57127 and CVE-2026-57131. Read the causes together rather than one at a time. In CVE-2026-57123 the tools server binds to all interfaces and creates its event-stream and message routes without invoking the authentication, origin-validation and DNS-rebinding protections that the product's own security configuration already provides, so any client that can reach it may list and invoke every registered tool. In CVE-2026-57131 the jobs router is mounted under its API path with neither authentication nor per-job authorisation, allowing an unauthenticated caller to submit agent configurations and to read, stream, cancel or delete other users' jobs. CVE-2026-57124 is unauthenticated command injection through a connect endpoint for Model Context Protocol tooling, and CVE-2026-57127 concerns authentication that does not engage at all when the expected environment variables are absent. Four further flaws in the same product were published the same day at 8.1 to 8.6, below the critical threshold but worth patching together with the rest: webhook handlers with no signature verification, server-side request forgery through a DNS validation bypass, command injection in an email tool, and unauthenticated agent invocation. Two more in the same window. CVE-2026-90919 affects ModelTC LightLLM through version 1.2.0 and was published on 14 September 2026, rated 9.3 on CVSS version 4 and 9.8 on version 3.1. The configuration server's registration endpoint takes the first frame a client sends on an unauthenticated WebSocket and passes it directly to Python's pickle loader, which is code execution by design of the format rather than by any error in the payload. No fix is recorded against it, and the stated mitigation is to restrict network access to that port. CVE-2026-12944 was also published on 14 September 2026 against IBM Langflow OSS versions 1.0.0 through 1.10.0, rated 9.6, and classified as server-side request forgery. An incomplete blocklist in the component scanner allows an authenticated user to submit components carrying socket or urllib imports and run arbitrary Python as root, with credential theft and lateral movement following from that. Note that this is a different flaw from CVE-2026-81204, which this publication carried on 15 September, and that a third Langflow issue, CVE-2026-9198, was added to CISA's Known Exploited Vulnerabilities catalogue on 5 August 2026.

Why it matters for IndiaThese are the components sitting under agent pilots in Indian banks, insurers, public sector undertakings, GCC platform teams, AI startups and university laboratories. The common condition is not carelessness. It is that these products ship with the protections available but inactive, and a team standing an instance up to demonstrate something in a fortnight has no reason to discover that the security configuration object was never passed in. What the instance then holds is the problem: provider keys for every model the organisation uses, a database connection string, and tool connections reaching into ticketing, code repositories and internal data. For a regulated entity that is customer data under the Digital Personal Data Protection Act sitting behind an endpoint that answers to anyone who can route to it.
ActionEstablish which of these you run by checking versions on hosts, not by asking teams, and include individual workstations and shared GPU servers. The fixed versions sit on two separate release lines, so confirm the fixed package and version against each CVE record individually rather than assuming one upgrade covers the set: CVE-2026-57123 is addressed in praisonaiagents 1.6.59, while CVE-2026-57131 is addressed in PraisonAI 4.6.58. For LightLLM, where no fix is recorded, restrict the configuration server port to named internal sources and verify that from outside the host. For Langflow, upgrade past 1.10.0 and treat component submission as a privileged action rather than an ordinary user action. Then run the check that matters more than any of these upgrades: for every inference and agent endpoint you operate, confirm from an unauthenticated client on another machine that it refuses you, because three of the flaws above are reachable precisely when nobody confirmed that.
SourceCVE-2026-57122, -57123, -57124, -57125, -57126, -57127, -57130, -57131 and -57132, MervinPraison PraisonAI and praisonaiagents (14 September 2026); CVE-2026-90919, ModelTC LightLLM (14 September 2026); CVE-2026-12944, IBM Langflow OSS (14 September 2026); CISA Known Exploited Vulnerabilities catalogue addition for CVE-2026-9198 (5 August 2026).
2

Mandiant's new AI report includes a case where an agent cost an organisation about fifty thousand dollars in under an hour, and there was no attacker in it at all

Mandiant and the Google Threat Intelligence Group published "AI Risk and Resilience 2026" in September 2026, reported on 16 September, organised around adversarial use of AI, offensive testing, securing AI systems and defensive architecture. The case that will travel furthest is an accounting agent that entered a runaway execution loop, made more than 15,000 high-cost API calls in less than an hour, generated roughly fifty thousand dollars in cloud charges, and disrupted live business transactions while doing it. No adversary features in that account. The agent had the permissions and the loop did the rest. The report's threat framing is narrower and more useful than the general commentary on this subject. A poisoned data source, a model dependency or an extension hook can turn a trusted agent into a channel for internal reconnaissance, lateral movement or escape from its sandbox, which places the exposure in the supply of context and tools rather than in the model's behaviour. Alongside that, the authors describe adversaries moving from prompting a model for research to orchestrating attacks with agents, and adaptive malware that changes its own code to defeat detection. Two earlier incidents are cited inside the report rather than disclosed by it: malicious OpenClaw skills carrying backdoors and information stealers in February 2026, and what the authors characterise as the first confirmed criminal use of an AI-developed zero-day exploit for mass exploitation in May 2026. The recommendations are conventional in the best sense: extend secure development practice to AI engineering, keep model and application inventories, generate dependency manifests automatically, collect telemetry on agent token consumption, API calls and access to sensitive assets, and match model capability to the task so that cost stays bounded.

Why it matters for IndiaThe runaway-agent case is the one to put in front of an Indian finance or operations leader, because it needs no threat actor and no disagreement about attribution. It is a control failure with an invoice attached, and Indian organisations are deploying exactly this pattern now: an agent given production credentials and an API budget in order to shorten a reconciliation or support process. The report does not describe Indian organisations among the affected, and we are not suggesting that it does. The supply-chain half is the part with longer consequences here, because Indian services firms and GCCs sit in the middle of other organisations' AI supply chains. An extension or tool connection that an Indian team writes and ships is somebody else's model dependency.
ActionPut a spend and rate ceiling on every agent that holds a provider key, and alert on the rate of calls rather than on the monthly total, since an hour-long loop does not show up in a monthly view until it is over. Give each agent an identity of its own rather than a shared service account, and record which tools, data sources and extensions it may reach. Treat any change to that list as a change requiring approval. Collect the telemetry the report names, particularly token consumption and access to sensitive assets, and put a threshold on it. Rehearse the stop: decide now who can halt an agent mid-run, how they do it, and how long that takes in practice.
SourceMandiant and Google Threat Intelligence Group, "AI Risk and Resilience 2026" (September 2026); Help Net Security (16 September 2026).
3

A cloned voice of a Chief Minister, a video on a social platform and a messaging-app number were enough to defraud people across several states, and an arrest followed this week

Tamil Nadu's Crime Branch Criminal Investigation Department arrested a man from Alwar district in Rajasthan on 12 September 2026 in connection with an AI-generated video impersonating Chief Minister C Joseph Vijay. The cyber crime cell is reported to have registered the case on 1 September 2026 and to have sought account and log information from the social media platform where the video circulated. A police team of deputy superintendent rank travelled to Alwar and the arrest followed with the assistance of the local police on 12 September; the accused was brought to Tamil Nadu on a transit warrant and remanded to judicial custody, and a mobile phone was seized. Police have said the investigation continues into whether others were involved. We are not naming the accused: the matter is before the courts and the outlets reporting it do not agree on the spelling of the name or on the age. The mechanics are worth stating carefully, because reporting differs on the lure while agreeing on the structure. The video carried Hindi-language cloned audio over the likeness of a Tamil Nadu public figure and circulated on Facebook and elsewhere. Some accounts describe it as offering financial assistance that viewers could claim by contacting a number on a messaging application; another describes an appeal for support towards education and medical treatment for poor children, with money reaching a personal account. Either way the shape is the same: a trusted face, a voice in a language chosen for the audience rather than for the person being impersonated, a public platform for reach, and a private channel where the fraud happens away from any moderation. Victims are reported across Madhya Pradesh and other states, which indicates the operation was not built around a local relationship at all.

Why it matters for IndiaThis is the deepfake threat as it actually arrives in India, and it does not look like the boardroom video call that dominates vendor briefings. It looks like a welfare scheme. The language choice is the detail defenders should absorb: Hindi audio over a Tamil Nadu figure worked because the target audience was not in Tamil Nadu, and the same production effort scales across every language pair in the country. Bank and NBFC fraud teams will see the downstream transfers before anyone sees the video. State government and public sector communication units are the impersonated party and are usually the last to find out. Insurers, lending platforms and large brands should expect their own executives in the next iteration, because the scheme depends on institutional trust rather than on any specific person.
ActionFor public-facing institutions, publish and maintain a single authoritative list of the channels through which you announce schemes, payments and assistance, and make "we never ask you to claim benefits through a messaging application" a standing line in every communication. Assign named ownership for monitoring impersonation of your leadership across platforms, since this is currently nobody's job in most organisations. Prepare the takedown path before you need it: which platform escalation route you use, who signs the request, and what evidence you preserve. For banks and payment providers, build the beneficiary-side detection, because accounts receiving small transfers from many unrelated payers across distant states are visible to you in a way the video is not. Train branch and call-centre staff on the current lure rather than on deepfakes in the abstract.
SourceDT Next (15 September 2026); ETV Bharat (16 September 2026), on the Tamil Nadu CB-CID investigation and arrest of 12 September 2026.
4

Australia's cyber agency has published guidance that moves the security question off the model and onto the apply, which is the part your organisation actually builds

The Australian Signals Directorate's Australian Cyber Security Centre published "Agentic AI applyes" on 11 September 2026. Its argument is a useful corrective. The apply is the software layer joining the model to your tools, systems and data, and it determines what information the agent receives, which tools it can reach, what actions it may take and which controls apply. Models are replaced every few months. The apply is a long-term investment that an organisation builds, configures and owns, and it is where the security properties of an agent deployment actually live. The guidance sets out five categories of risk: privilege risk, where a compromised agent reaches further than it should; design and configuration risk, introduced before anything is deployed; behavioural risk, covering unintended actions, prompt injection and data poisoning; structural risk, where failures cascade across interconnected components; and accountability risk, where a decision cannot be traced through a complex system afterwards. The controls it recommends are least-privilege access and proper identity management for agents, human oversight for high-impact actions, restrictions on which external data and tools an agent may reach, output validation and audit logging, and phased deployment with security validation at each stage. Its central statement is the one to quote in an internal paper: no apply is inherently secure. Survey data published in the same week suggests how far that message has to travel. OneTrust released its 2026 AI-Ready Governance Report on 14 September 2026, based on a Sapio Research survey of 1,200 senior business decision-makers across the United States, Canada, the United Kingdom, France, Germany, Spain, Australia and Singapore. India was not in the sample, so read it as a signal about comparable markets rather than a measurement of Indian practice. Eighty-six per cent reported at least one AI-related incident in the past year across the categories measured, including exposure of sensitive data and unapproved staff use of AI tools. Eighty-seven per cent encourage the use of AI agents while forty-seven per cent have clear governance, oversight and controls for them, and five per cent report clear accountability across the full AI lifecycle. A third said staff turned to unapproved tools because the approved options were not available quickly enough, which is a procurement finding as much as a security one.

Why it matters for IndiaIndian organisations are largely buying models and building applyes, which is exactly the split this guidance addresses. The integrator assembling an agent workflow for an Indian bank is building the apply; the bank owns the consequences and frequently has no document describing what that apply may reach. The accountability risk category is the one to carry into a compliance conversation, because CERT-In's reporting obligations require an organisation to reconstruct what happened, and if an agent takes an action nobody can trace, that reconstruction cannot be produced. The shadow-AI finding deserves a plainer reading than it usually gets: staff went around the approved path because it was slow, so part of the security answer is a delivery answer.
ActionWrite down, for each agent system you run, which apply it uses, who built it and who maintains it, because in many Indian deployments the honest answer will name a vendor rather than anyone internal. Give each agent its own identity with scoped permissions instead of inheriting a developer's or a service account's. Decide which actions require human approval and enforce that in the apply rather than in a prompt. Log tool calls and outputs to a place the agent cannot write to. Deploy in stages with a security check at each one rather than moving a pilot into production because it worked.
SourceAustralian Signals Directorate's Australian Cyber Security Centre, "Agentic AI applyes" (11 September 2026); OneTrust 2026 AI-Ready Governance Report, survey conducted by Sapio Research (14 September 2026); Help Net Security (15 September 2026).
AI defender tip: Put these four items next to each other and one sentence explains all of them. In every case the control existed and was not connected to anything. The tools server had a security configuration object that was never passed in. The jobs endpoint had an authentication layer that was never mounted. The accounting agent had a spending limit available on the provider account that nobody had set. The apply guidance exists because organisations are deploying agents whose permissions no document describes. Even the deepfake case turns on this: state governments have official channels, and the fraud worked because no ordinary citizen had a way to check a video against them. This is a different problem from the one most AI risk registers are written to address, and a considerably more tractable one, because it does not require you to predict what a model will do. The exercise this week takes two hours. Pick the three AI systems your organisation is actually running, not the ones in the strategy document. For each, find the security control the product already offers and answer one question about it: is it switched on, and who verified that from outside the system rather than from the configuration file. Authentication on the endpoint. Origin validation on the tools server. A spending cap on the provider key. An approval step before a high-impact action. An audit log the agent cannot reach. Most teams will find at least one of those available, documented by the vendor and never enabled, and they will find it faster than they expect, because the answer is usually that nobody was ever asked to enable it.

Nirad Threat Research

Nirad AI Threat Watch | Bharat-first threat intelligence