CAPTCHAs Lost to AkiraBot on 80,000 Sites. Here Is Captcha-Free Form Protection

This article was written with AI assistance and reviewed by the author.

In April 2025, SentinelLABS published research on AkiraBot: an AI-powered spam framework that targeted more than 420,000 websites and successfully spammed at least 80,000 of them since September 2024 [1]. It used OpenAI to generate custom outreach for each site, then pushed those messages into contact forms and chat widgets. The operators also invested heavily in defeating CAPTCHAs, including hCAPTCHA, reCAPTCHA, and Cloudflare Turnstile [1].

That is the uncomfortable part. The industry's most common "prove you are human" control is on the target list for commodity spam tooling. If CAPTCHA is optional for the attacker, what does a contact form owner actually have left?

Form spam is an automated threat, not a UX bug

OWASP lists form and content spam as OAT-017 Spamming in its Automated Threats taxonomy: automated addition of malicious or questionable content and messages, including SEO and form spam [2]. A related threat, OAT-009 CAPTCHA Defeat, covers the other side of the same fight: automation that solves or bypasses anti-automation puzzles with OCR, image databases, or human solver farms [3].

OWASP's Bot Management cheat sheet is blunt about visible CAPTCHAs: they are accessibility-hostile, increasingly machine-solvable, and available to solver farms for fractions of a cent [4]. The W3C's Inaccessibility of CAPTCHA note has made the same accessibility case for years: visual and audio challenges routinely exclude people who should still be able to use the form [5].

So the failure mode for a typical contact page stacks up like this:

1. A bot finds the form (or buys a target list).
2. It fills every field, including ones humans never see if the honeypot is weak or missing.
3. If there is a CAPTCHA, a bypass service or farm solves it.
4. Your inbox fills with SEO pitches, fake leads, or worse.

A puzzle in front of every visitor is the wrong primary control. You want checks that cost almost nothing for a real browser session and raise the price of bulk automation.

Cheap layers that bots fail

That is the design behind form-honeypot-guard, a captcha-free package I built for Node apps:

• an off-screen, accessible honeypot field with a randomised, realistic name on each build;
• an HMAC-signed timing token, so submissions that arrive too fast, too late, tampered, or replayed are rejected;
• a JS proof field that only a real browser fills, plus light interaction signals (keypress, pointer, focus);
• optional content heuristics (link spam, URLs in name fields, spam keywords);
• sliding-window rate limiting per IP (and optionally per email or fingerprint), with a correct 429 and Retry-After;
• optional Altcha-style proof-of-work when you want a stronger challenge without a captcha vendor.

The client runtime is under 2 kB gzipped. Webpack and Vite plugins inject the honeypot markup at build time, randomise field names, and write a manifest the server reads. Helpers cover Express/Connect, Fastify, Next.js, SvelteKit, Remix, Astro, and plain Fetch runtimes, plus an optional React wrapper.

Auditing built HTML with the CLI

Protecting forms is half the story. The other half is noticing when a form shipped without the trap. The CLI audits built HTML:

npx form-honeypot-guard check dist --strict

The demo below is made up for this article: two HTML files under demo/dist with an unprotected POST contact form, a newsletter form that accidentally uses GET (so the email would land in the query string), and one form that already looks partially guarded. Real output from version 1.1.1:

Two errors and two warnings:

• a POST form with no honeypot;
• a GET form that would put personal data in the URL;
• CSRF token warnings on both POST forms (the checker reminds you; SameSite cookies alone are not always enough).

--strict treats warnings as errors and exits 1, which is what you want in CI. form-honeypot-guard secret prints a fresh HMAC secret for FORM_GUARD_SECRET.

Wiring the guard into a build

Mark forms with data-guard (or guard all of them), then add the webpack plugin:

const { FormGuardPlugin } = require('form-honeypot-guard/webpack');

new FormGuardPlugin({
  forms: 'form[data-guard]',
  secretEnv: 'FORM_GUARD_SECRET',
  minTime: 3000,
  manifestPath: 'server/form-guard.manifest.json',
});

On the server (Express example):

import { expressGuard, cleanFields } from 'form-honeypot-guard';

app.use(expressGuard({
  manifest: 'server/form-guard.manifest.json',
  paths: ['/contact'],
  rateLimit: { limit: 5, windowMs: 60_000, keys: ['ip', 'email'] },
}));

And in CI, after the frontend build:

- run: npm run build
- name: Audit forms for honeypot coverage
  run: npx form-honeypot-guard@1 check dist --strict

The takeaway

AkiraBot showed that LLM-written spam plus CAPTCHA bypass can hit hundreds of thousands of sites [1]. OWASP already treats form spam and CAPTCHA defeat as first-class automated threats [2][3], and both OWASP and W3C warn against leaning on visible CAPTCHAs as the main defense [4][5]. Layer cheap server-checked signals instead, and fail the build when a form ships unprotected.

• Site: https://mrlouiswright.github.io/form-honeypot-guard/
• npm: https://www.npmjs.com/package/form-honeypot-guard
• GitHub: https://github.com/MrLouisWright/form-honeypot-guard

References

1. Delamotte, A. and Walter, J. (SentinelLABS / SentinelOne). "AkiraBot | AI-Powered Bot Bypasses CAPTCHAs, Spams Websites At Scale". 2025. https://www.sentinelone.com/labs/akirabot-ai-powered-bot-bypasses-captchas-spams-websites-at-scale/
2. OWASP. "OAT-017 Spamming". OWASP Automated Threats to Web Applications. Accessed Oct 2026. https://owasp.github.io/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-017_Spamming.html
3. OWASP. "OAT-009 CAPTCHA Defeat". OWASP Automated Threats to Web Applications. Accessed Oct 2026. https://owasp.github.io/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-009_CAPTCHA_Defeat.html
4. OWASP. "Bot Management and Anti-Automation Cheat Sheet". Accessed Oct 2026. https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html
5. W3C. "Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web". W3C Working Group Note. Accessed Oct 2026. https://www.w3.org/TR/turingtest/