Recaptcha Bundle Laravel Package

Product Decisions This Supports

• Bot mitigation build-vs-buy. This package represents the "buy/reuse" option for adding a CAPTCHA to forms. Its state — a Symfony-only bundle whose latest tag (2.2 / "Version 3") points at the same commit that was already pinned in composer.json, i.e. a re-tag with no code delta — is direct evidence that reuse is not viable here and a thin in-house integration against Google's current reCAPTCHA API is the cheaper path.
• Security & abuse-prevention roadmap. CAPTCHA is a defensive control on signup, login, password reset, contact, and checkout forms. Any roadmap item that depends on spam/credential-stuffing reduction should not be scoped against this dependency.
• Compliance and vendor surface. CAPTCHA vendors are a privacy/governance decision (third-party script, data sent to Google, consent implications under GDPR/ePrivacy). A 2014-era bundle locks you to whatever reCAPTCHA generation it targeted, which is a compliance liability rather than an asset.
• Platform scope decision (Laravel vs. Symfony). This is a Symfony bundle, not a Laravel package — EWZRecaptchaBundle registers a form type and DI extension. If the product is Laravel-based, this is not a candidate at all; that framing should be corrected before it reaches a backlog.
• Legacy portfolio triage. If you inherited a Symfony 2.x app already depending on it, this flags a modernization item: replace the CAPTCHA integration, not just upgrade the framework.
• Release-signal hygiene. The new "Version 3" tag is a version bump with no accompanying code change. Treat version numbers and "new release" events as claims, not evidence of maintenance: a tag that resolves to an unchanged commit delivers zero of the things a release is supposed to deliver (fixes, compatibility, CVE coverage). The raw "opportunity: 9.35" score should likewise be discounted — it is derived from metadata, not from fitness. Use both as a prompt to investigate, never as a green light.

When to Consider This Package

Consider it only in one narrow case:

• You are maintaining a legacy Symfony 2.x application that already has this bundle wired into its forms, and you need a short-term, no-code-change reason to keep it while planning replacement. Even then, verify it still functions — Google retired the reCAPTCHA v1 endpoint in 2018, so any v1-era widget is already broken in production. The 2.2 tag changes nothing about this check; it is the same code you are already running.

Look elsewhere — decisively — when any of the following is true:

• You are on Laravel, or any non-Symfony framework. The bundle's value is in Symfony form-type and service-container integration; none of that transfers. There is no meaningful code to lift.
• You are on a supported Symfony version (4.x+, 5.x, 6.x, 7.x). The bundle predates Symfony 3 and will not autowire or boot correctly.
• You need reCAPTCHA v3 (score-based, invisible) or Enterprise. This predates both.
• You care about security maintenance. A CAPTCHA integration is part of your attack surface; an unmaintained dependency with zero dependents has no CVE coverage, no maintainer, and no patch path. A new tag on an unchanged commit does not alter that — it does not shorten the patch path by a single line.
• You want a lower-friction vendor. Cloudflare Turnstile and hCaptcha are reasonable alternatives to re-evaluate at the same decision point; a modern reCAPTCHA v3 client is also a small, well-documented integration.

Preferred references for the "what to do instead" slide: google/recaptcha (PHP, framework-agnostic), ewz-recaptcha-bundle's actively forked successors, or the Laravel ecosystem's maintained CAPTCHA packages.

How to Pitch It (Stakeholders)

Executive summary — recommend: do not adopt. This is a Symfony form helper for reCAPTCHA with 3 GitHub stars, zero dependent projects, and effectively no functional change since 2014. The newly published 2.2 ("Version 3") tag re-points to the same commit already in use — a repackaging, not maintenance. It is not a Laravel package and cannot be used in a Laravel codebase. Its maintenance status makes it a security liability rather than an accelerator: CAPTCHA is a defensive control, and an unpatched dependency on your login and signup forms is the wrong place to save two days of engineering.

The cost comparison is lopsided. Integrating Google's current reCAPTCHA (v3) or Cloudflare Turnstile directly is a small, well-documented task — on the order of a day or two of engineering plus QA, per platform. Adopting this bundle buys near-zero savings, adds an unmaintained third-party dependency to a security-sensitive flow, and still forces an inevitable migration later. A version tag does not change that math.

For engineering: treat this as a rejected candidate, not a backlog item. Concretely: (1) if any legacy Symfony 2.x service currently uses EWZRecaptchaBundle, audit whether its CAPTCHA still renders — v1 was retired in 2018, so it may already be failing silently; (2) do not treat the 2.2 release as a signal to re-open evaluation — diff it against the previously pinned commit and you will find nothing new to evaluate; (3) scope a replacement to reCAPTCHA v3 or Turnstile as a standalone integration with no framework-bound dependency; (4) do not evaluate further based on the "opportunity" score, which reflects metadata signals rather than fitness for our stack.

One-line ask: approve a small replacement spike for CAPTCHA on public forms, and retire this package from consideration.