CERT-In Warns Lenders and Wallets of Attackers Calling Payout APIs Directly

India's national incident response team, CERT-In, told non-bank lenders, fintechs, payment providers and wallet operators on Oct. 9 that attackers are stealing payment-gateway and bank API credentials and moving money without touching the checks that sit in front of the payout. The advisory, numbered CIAD-2026-0046 and rated critical, was issued jointly with its finance-sector arm, CSIRT-Fin.

The requirement for the attacker is a foothold on an internet-facing application, an exposed API or a privileged endpoint. After that, according to the advisory text, the attacker calls the disbursal and fund-transfer APIs from the victim's own allow-listed infrastructure.

What the attackers skip

Because the calls go straight to the payment layer, they never pass loan creation, KYC, sanctions screening, beneficiary verification, balance checks or transaction limits. Those controls usually live in the application in front of the API. The money goes to mule accounts across several banks and is withdrawn immediately, the advisory says, and it describes rapid series of high-value IMPS and NEFT transfers, two Indian bank transfer systems.

The advisory lists six ways in. Beside each below is the closest control it asks for, a pairing drawn from its recommendations section rather than a mapping CERT-In made.

How attackers get in	Closest control the advisory asks for
Exposed application and middleware flaws	Remove internet exposure of internal applications
Deprecated or unauthenticated APIs with unrestricted file upload	Keep an API inventory, decommission unused APIs
Long-lived static API tokens hard-coded in source	Per-session authentication on all APIs
Forged commits in source repositories	Isolated development, test and production environments
Plaintext credentials in config files or databases	Secret managers or HSMs, with rotation
Applications and remote services without MFA	MFA on payment platforms, admin portals and bank APIs

After compromise, it says, attackers install web shells and backdoors, map the payment databases and API integrations, then invoke the transfers. Log deletion or truncation, tampering with endpoint detection tools and other anti-forensic cleanup follow.

The photograph is a file image of a central bank office. The advisory does not name the Reserve Bank, a regulator action or any affected company.

The controls on the payout path

The sentence in the advisory that only a reader of the full text would find is the instruction to "cryptographically bind" multi-stage transaction flows so a debit API cannot run without a prior validation step. That is the direct answer to the bypass: it moves the KYC and limit checks from the application into the sequence the payment API itself enforces.

The other transaction controls are conventional. They are maker-checker approval, a second person releasing every fund movement, per-transaction and per-day cumulative limits enforced at the API, penny-drop and name-matching on beneficiaries, and rejection of any payout whose reference ID has no matching record. The last one targets the dummy reference numbers the advisory lists among its behavioral indicators.

For monitoring, the advisory asks for real-time transfer monitoring with automated holds, near-real-time reconciliation against bank and aggregator statements, centralized logs retained at least 180 days, and egress allow-listing on production servers.

What the advisory does not say

There are no IP addresses, file hashes or domains. The only network indicator is that attacker addresses "mostly" belong to hosting providers. CERT-In does not give the number of campaigns it has seen or the amount of money moved. It says the attacks may have used AI-assisted tooling and that the gap between initial compromise and fraud has narrowed, without a before and after figure.

MediaNama, which reported the advisory, wrote that the recommendations are mostly well-known controls that can be shown as compliance on paper without being implemented, and that CERT-In gives little feedback to entities that report incidents.

One of the six entry routes overlaps with a pattern covered here before. Forged commits in source repositories are the same class of attack as the npm slug-takeover findings, and hard-coded tokens are what the Docker Hub conversion-token flaw put at risk.

Entities that suspect a compromise are asked to disable affected accounts, suspend the exposed APIs, preserve evidence, rotate every credential and report to [email protected] with logs.