On 9 October 2026, CERT-In and CSIRT-Fin issued advisory CIAD-2026-0046, rated Critical, on campaigns against Indian NBFCs, digital lenders, fintechs, payment service providers and wallet operators. Attackers compromise an internet-facing application, steal payment gateway and partner bank API credentials, and then call disbursal and fund-transfer APIs straight from the victim's own whitelisted servers. That route skips every control the application enforces: loan creation, KYC, sanctions screening, beneficiary verification, balance checks and per-transaction limits.
What's affected
The advisory does not name a product or CVE. It describes a pattern that targets how payment integrations are built.
Initial access, according to CERT-In:
- Exploited internet-facing applications and application server middleware.
- Deprecated, unauthenticated or unused APIs that allow unrestricted file upload.
- Long-lived static API tokens hard-coded in source code.
- Source repositories compromised through forged commits.
- Plaintext credentials in configuration files, code or databases.
- Applications and remote services without MFA.
After access, attackers install web shells, survey payment databases and integrations, steal gateway and bank credentials, and call fund-transfer APIs. Fraudulent transfers use dummy reference IDs with no matching loan or transaction, exceed per-transaction limits, go out quickly over IMPS and NEFT to mule accounts across several banks, and are withdrawn at once. Attackers then delete or truncate logs and tamper with EDR. CERT-In notes reports of AI-assisted tooling and a much shorter time from compromise to fraudulent transfer.
The key point for developers: the bank's API trusts your server and your credentials. If the only thing standing between an attacker and a payout is application logic that runs before the API call, stealing the credential removes it.
Does this apply to you?
CERT-In advisories are recommendations. Separately, CERT-In asks that suspicious activity tied to this campaign be reported to incident@cert-in.org.in with relevant logs. Check these criteria:
- You are an NBFC, digital lender, fintech, PSP or wallet operator in India, or you build software for one. You match the target list.
- Your servers hold credentials that can move money through a payment gateway or partner bank API.
- A debit or disbursal call can succeed without a server-side check that it matches an approved record. If your payout service accepts any reference ID, this attack works against you.
- Any API key in your environment is long-lived and static, or sits in code, config or a database in plaintext.
- You have old or test APIs still reachable from the internet, especially ones that accept file uploads.
What to do now
- By 23 October 2026: inventory every credential that can initiate a fund movement. Move each into a secrets manager or HSM, rotate it and record who and what can read it.
- By 23 October 2026: enforce MFA on payment platforms, admin portals, payment and bank APIs and remote access services.
- By 31 October 2026: make the payout service reject any transfer whose reference ID has no matching approved record, and enforce per-transaction and daily cumulative limits at the API and payment layer, not only in the front end.
- By 15 November 2026: cryptographically bind multi-stage transaction flows so a debit call cannot run without its preceding validation steps, and require maker-checker approval for fund movements.
- By 15 November 2026: retire deprecated and unused APIs, allow-list outbound traffic from production servers, and isolate development, test and production.
- By 30 November 2026: monitor transfers in real time for velocity, amount bands and new beneficiaries with automatic holds, reconcile with bank statements in near real time, centralize logs for at least 180 days and deploy tamper-protected EDR.
- If you see signs of compromise: disable affected accounts, suspend affected APIs, preserve evidence, rotate all credentials and report to CERT-In.
A quick way to start step 1 is to search code and config for anything that looks like a gateway key:
grep -rEn --exclude-dir={.git,node_modules} '(api[_-]?key|secret|client[_-]?secret|bearer)\s*[:=]' .
Why it matters
This is a design problem as much as a security one. Many payment integrations put the business checks in the application and treat the downstream API as a dumb pipe. CERT-In's advice is to push the checks down: validate against records at the payout layer, bind the steps of a transaction together and assume the credential will leak at some point.
The initial access list is also familiar from CERT-In's AI agent advisory, CIAD-2026-0049, published six days later: static tokens in code, forgotten APIs, plaintext keys, missing MFA. Fixing those closes the door for both kinds of attacker.
Try it yourself
Take your payout or disbursal API and write down every check performed before money moves. Mark which checks run inside the service that holds the bank credential and which run upstream. Anything upstream is bypassed if that credential is stolen. Then test the API's exposed endpoints for authentication and authorization gaps.
Click through it at your own pace, or open it full screen.
Quick check
Why do the fraudulent transfers bypass KYC and transaction limits?
Because attackers call the fund-transfer APIs directly with stolen credentials from the victim's own whitelisted infrastructure, skipping the application logic where those checks run.
What does CERT-In recommend instead of long-lived static API tokens?
Per-session authentication for all APIs, with credentials stored in a secrets manager or HSM and rotated.
Where should suspicious activity linked to this campaign be reported?
To CERT-In and CSIRT-Fin at incident@cert-in.org.in, with all relevant logs.
