CERT-In published a vulnerability note on 1 September 2026 covering three flaws in Manacle Technologies' Multi-tenant ERP System. The worst is an unauthenticated file upload leading to remote code execution, which CERT-In scored at CVSS v4.0 10.0. The note names no fixed version. Its remediation advice is to contact the vendor.

Your vulnerability scanner will not flag this. Not because the CVE is absent from the National Vulnerability Database — it was published there the same day — but because the record arrived without the one field that makes automated detection work.

If you run Indian-built enterprise software, that is your normal operating condition. And it does not appear as a gap on any dashboard you own.

What CIVN-2026-0430 actually says

CERT-In rates the note HIGH. It covers three issues, all credited to researcher Nisarga Adhikary.

  • CVE-2026-84147 — an API endpoint that neither authenticates the request nor validates the uploaded file type (CWE-434). An unauthenticated attacker writes an arbitrary file into a web-accessible directory and executes it. CERT-In's vector is AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Every subsequent-system metric is High, meaning CERT-In assesses that compromise crosses the tenant boundary.
  • CVE-2026-84148 — an authorisation bypass in the same API. Manipulate a parameter, read another user's data. CERT-In scored it 9.2.
  • CVE-2026-84149 — a publicly reachable .git directory (CWE-527), exposing repository metadata and allowing reconstruction of application source.

Read together, these are not three separate bugs. They describe one application where the source code is downloadable, the authorisation model is decorative, and the upload endpoint is open to the internet. An attacker who pulls the repository first does not have to guess at the upload path or the file naming convention. The .git exposure is what turns the other two from theoretical into trivial.

CISA's ADP enrichment attached to CVE-2026-84147 records exploitation as none observed, automatable as yes, and technical impact as total. Do not read the first of those as comfort. Automatable, total impact, and a leaked source tree is a mass-scanning profile.

Why the scanner stays quiet

Commercial scanners match findings to CVEs through CPE — the structured product identifier that tells software, unambiguously, which vendor and which versions are affected. No CPE, no match, no plugin, no finding.

I pulled all three Manacle records from the NVD API on 11 September 2026. None carries a CPE configuration. All three show a vulnStatus of Deferred. The only CVSS metrics present come from the source identifier vdisclose@cert-in.org.in, which is CERT-In itself. NVD has contributed nothing beyond storage.

CVEFlawCERT-In CVSS v4.0NVD statusCPE data
CVE-2026-84147Unauthenticated file upload to RCE10.0 CriticalDeferredNone
CVE-2026-84148Authorisation bypass (IDOR)9.2 CriticalDeferredNone
CVE-2026-84149Exposed .git directoryNot separately publishedDeferredNone
CVE-2026-45431Command injection, GX Earth ONT8.7 HighDeferredNone

The last row matters because it shows this is not a one-off. CIVN-2026-0288, dated 4 June 2026, covers command injection, cleartext credential transmission and a hardcoded cryptographic key across GX Earth ONT models sold in India. Identical pattern: CERT-In assigns the CVEs, CERT-In supplies the only CVSS, NVD defers, no CPE is ever generated.

NIST's own policy explains the mechanism rather than any conspiracy. NVD has dropped routine enrichment for all previously unenriched vulnerabilities reported before 1 March 2026, and now prioritises two categories: software used by the US federal government or designated critical under Executive Order 14028, and entries on CISA's Known Exploited Vulnerabilities catalogue. An ERP platform deployed almost exclusively inside one country satisfies neither test. It will not reach KEV, because KEV reflects exploitation observed against American networks. So it is never enriched, never gets a CPE, and never becomes a scanner plugin.

The problem is not that CERT-In's findings are missing from Western feeds. They are in the feeds. They are simply inert — a CVE identifier with no machine-readable product binding, which your tooling ingests, fails to match, and silently discards. Absence you would eventually notice. This you will not.

One hundred and forty-seven records

A query against the NVD API for records carrying CERT-In's source identifier returned 147 results in total, covering 2022 to the present. The products named in those entries tell you what this corpus is for: Tacitine Firewall EN6200-PRIME appliances, Milesight video management systems, a TP-Link TL-WR841N hardware revision. Kit that is everywhere in Indian networks and nowhere in a Gartner quadrant.

Now set 147 against CERT-In's publishing volume. By 10 September 2026 its numbering had reached CIVN-2026-0453 — that day's note covered a privilege escalation in Microsoft Defender. The overwhelming bulk of what CERT-In publishes is restatement of advisories from Cisco, Microsoft, Oracle and the rest, which your existing feeds already carry. The original India-product research is a thin trickle by comparison. It is also the only place that research exists.

The AI advisory, and the Microsoft drumbeat

Separately, CERT-In issued a high-severity advisory on AI-driven attack capability, reported as CIAD-2026-0020 and dated 26 April 2026. Coverage of it describes warnings about large-scale automated code analysis for zero-day discovery, accelerated exploit development, automated reconnaissance and AI-generated multilingual phishing, with MSMEs singled out as the exposed population. The recommended controls were conventional: patch critical vulnerabilities within 24 hours, enforce MFA, increase monitoring cadence, review legacy VPN estate. I could not retrieve the advisory text from CERT-In directly, so treat the reference number as reported rather than confirmed.

One widely repeated set of figures — 2.72 billion attacks against India's banking sector in the preceding year, DDoS attempts up 2.7 times, exploit attempts up 2.5 times — comes from Indusface, a vendor selling application security into that market. Worth knowing, worth discounting accordingly.

CERT-In also mirrors Microsoft's monthly releases into its own advisories covering Windows 10, Windows 11, Windows Server, Office and Edge. If you already track Patch Tuesday, these add nothing. Do not let them crowd your attention away from the notes that do.

Folding CERT-In into vulnerability management

CERT-In publishes no RSS feed that I could find, and its mailing list subscription runs through a PDF form you email in. That is not a workflow. Build your own.

  1. Inventory your Indian-origin software first. ERP, payroll, HRMS, banking middleware, GST filing tools, ONT and CPE hardware from domestic suppliers, anything procured to meet a government tender requirement. If it is not on a list, no process will protect it.
  2. Poll the NVD API by source identifier. Query services.nvd.nist.gov/rest/json/cves/2.0?sourceIdentifier=vdisclose@cert-in.org.in on a daily schedule and diff the results. This is the single highest-value automation in this article: it gives you every CERT-In-originated CVE in machine-readable form, which the CERT-In website will not.
  3. Scrape the vulnerability note index as well. Notes are addressable at predictable URLs of the form s2cMainServlet?pageid=PUBVLNOTES01&VLCODE=CIVN-2026-NNNN. Walk the sequence. Notes appear there before, and sometimes without, a corresponding CVE.
  4. Write your own CPE strings. Most scanners accept custom detection or asset tagging. Bind your inventory entries to the CERT-In CVE identifiers by hand. Tedious once, then permanent.
  5. Treat absent version data as affected. CERT-In notes frequently omit version ranges because the vendor never supplied them. Default to vulnerable until the supplier tells you otherwise in writing.
  6. Put patch commitments in the contract. A remediation instruction that reads "contact the vendor" is only actionable if the vendor has agreed in advance to respond. For domestic software suppliers, most have not.

There is a compliance edge to this that Indian organisations should not miss. Under the CERT-In directions issued in April 2022 under Section 70B(6) of the IT Act, in force since 28 June 2022, covered entities must report specified cyber incidents within six hours of becoming aware of them. If you are compromised through a flaw CERT-In itself published, and your answer to the regulator is that your scanner did not pick it up, you are explaining why you did not read the notices issued by the body you are obliged to report to.