CERT-In's 12-Hour Patch Rule and AI-Built Apps
India's CERT-In set a 12-hour patch deadline for critical flaws. Why AI-built and vibe-coded apps are most exposed, and how to close the gap.
India's CERT-In, the country's national cybersecurity agency, has set a tight new deadline. Critical flaws in public-facing software now need to be patched within 12 hours. The push follows an April 26, 2026 advisory on how AI is changing the speed and scale of cyberattacks.
If you run a product, ship code, or own infrastructure exposed to the public internet, this affects you. The window between a flaw becoming public and someone weaponizing it has collapsed.
What the advisory actually says
The advisory describes AI tools that can scan large codebases for vulnerabilities, write working exploits, run reconnaissance across cloud and API surfaces, and stitch all of it into multi-stage attacks with almost no human input. The skill barrier to exploit a known CVE used to be a meaningful filter on who could attack you. That filter is mostly gone.
CERT-In recommends a Zero Trust posture, aggressive patching of internet-facing assets, AI-focused cyber drills, and stronger incident response plans. The 12-hour benchmark is the headline. The underlying point is broader. Defenders now need automation that keeps pace with the automation attackers already have.
Why vibe-coded apps sit in the blast radius
A vibe-coded app is software generated mostly through AI coding tools and shipped fast. It tends to inherit three problems that compound under a 12-hour patch rule.
The first is dependency sprawl. AI code generators pull in packages liberally. Many of those packages carry unpatched CVEs by the time the app reaches production. Nobody on the team chose them deliberately, so nobody is tracking them.
The third is the absence of a maintenance plan. The build is a sprint. There is no on-call rotation, no scheduled dependency review, no monitoring of CVE feeds against the actual stack in production. When a new exploit drops, nothing in the system is watching.
Under a 12-hour window, all three of these turn an ordinary disclosure cycle into an incident.
What to do about it
Treat security as a recurring line item rather than a launch checklist. Know what dependencies ship in production, watch the CVE feeds against that list, and write the emergency patch playbook before the emergency. The technical floor is an accurate SBOM on every deploy, dependency scanning wired into CI, and alerts tied to CISA KEV and CERT-In bulletins.
Layer manual review on top of all of it. The failures that show up in postmortems live in the seams between services, in auth flows that break under adversarial pressure, in the gaps the model glossed over because they did not affect the happy path. That is where VibeAudits works.
A 12-hour patch window is a high bar. The teams that hit it built the muscle before the bulletin landed.