On October 23, 2026, the researcher Nemo (@captn3m0) posted that India's UPI operator NPCI "has been running on an expired cert since Sep 2025," issued by IDRBT, which the post says now manages all *.bank.in certificates. The follow-up claim is the interesting part: UPI has not gone down because the code "doesn't even validate the certificate, it just encrypts the data with its public key." We have not inspected the package ourselves, and parts of the thread are disputed.
TL;DR
| Question | Answer |
|---|---|
| Is a UPI certificate expired? | Reported: signer-upi.crt expires 2025-09-19 per a table shared with the claim. Not independently verified by us |
| Is an eRupee certificate expired? | Reported: signer-erupee.crt expires 2024-10-01. Not verified by us |
| Why does UPI still work? | Claimed: the code encrypts with the public key and never checks validity |
| Is it confirmed by NPCI? | No NPCI statement found at time of writing |
| Disputed? | Yes. One replier said it may be an old certificate that was never removed |
| Does it mean payments can be intercepted? | Not shown by anything published |
What is reported
The table shared with the claim lists two files found in an Android package (APK):
| File in APK | Subject | Issuer | Valid from | Expires |
|---|---|---|---|---|
signer-erupee.crt | CN=psosigner.npci.org.in (National Payments Corporation of India, Chennai) | DigiCert EV RSA CA G2 | 2023-09-01 | 2024-10-01 23:59:59 GMT |
signer-upi.crt | CN=upinpci | IDRBT Sub CA 2022 | 2023-09-20 | 2025-09-19 18:29:59 GMT |
The post's author wrote that "UPI uses it for encrypting payloads that reach NPCI. Not every certificate is browser/TLS." Another account, Srikanth (@logic), published a write-up at cashlessconsumer.zo.space/npci-expired-cert that the original poster cited as validation. Our reading was limited to the thread text and the table above.
Claimed vs verified
| Claim | Status | Source |
|---|---|---|
| UPI signing certificate expired 2025-09-19 | Reported, certificate table only | Thread, Oct 23 |
| eRupee certificate expired 2024-10-01 | Reported, same table | Same |
IDRBT issues certificates under *.bank.in | Stated by the poster; not checked by us | Same |
| The certificate is actually used for payload encryption | Claimed; cited to a third-party write-up | Same |
| Client code ignores certificate validity | Claimed; we have not seen the code | Same |
| NPCI confirmed or commented | None found | |
| It may be a stale file, not an active one | Raised by a skeptic in the thread | Same |
Why "expired" and "broken" are different things
A TLS client checks the validity period as part of building a chain to a trusted root, so an expired server certificate breaks the connection. A client that merely takes a public key out of a bundled file and encrypts to it has no such step unless the developer wrote one. If that is how this works, expiry has no runtime effect, which would explain why nothing visibly failed.
That also explains why expiry matters for a different reason. A check that never runs cannot tell the app that the key is stale, revoked or swapped. Whether that is exploitable depends on how the app gets the file and whether it can be replaced, which the thread does not show.
What it means if you build with coding agents
The pattern is easy to produce by accident. An agent asked to "encrypt this payload to the partner's key" will often write code that loads a certificate, pulls out the public key and encrypts, and a reviewer sees working tests and moves on. Nothing in the happy path exercises expiry.
Things to do this week:
- List every bundled
.crt,.pemand.cerfile in your repos and print its expiry:
git ls-files '*.crt' '*.pem' '*.cer' | while read f; do
echo "$f: $(openssl x509 -in "$f" -noout -enddate 2>/dev/null)"
done
- Search for the code that loads each one, and check whether it validates the validity period and the chain, or only extracts a key.
- Add a test that fails when a bundled certificate has fewer than, say, 60 days left.
- When an agent writes this code, ask it to state what it validates and what it assumes, then read the result yourself.
Beam's scanner is a heuristic pattern check on skills and MCP configs. It does not inspect certificate handling in your application code, so this audit is a manual or CI job.
What to watch for
- A statement from NPCI or IDRBT.
- Independent analysis of the package that confirms which certificate is loaded and whether expiry is checked.
- Whether the certificates are replaced, and whether apps that bundle them are updated.
We will update this post if NPCI or a named research team confirms or refutes the claim.
Related reading
- October 2026 attacks timeline
- Rand Mutual Assurance breach claim: claimed vs verified
- PwC Everest breach claim: claimed vs verified
Sources: Nemo (@captn3m0) thread, Oct 23, 2026; Srikanth (@logic) write-up
Details are accurate as of October 23, 2026. This is a developing claim and may change.