<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-21T20:27:30.068403+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-113667</id>
    <title>fkie_cve-2026-113667</title>
    <updated>2026-10-21T20:27:30.079980+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>ApostropheCMS is an open-source Node.js content management system. Prior to 1.5.5 of the Form add-on, 1.2.1 of login-recaptcha, and 1.3.0 of login-hcaptcha, these three CAPTCHA integrations interpolate an unencoded user-supplied response token into the provider verification request. Crafted tokens can smuggle request parameters and disrupt CAPTCHA verification and CAPTCHA-gated form or login flows; automated bypass probing is possible, but a successful CAPTCHA bypass or secret disclosure is not established. This issue is fixed in Form 1.5.5, login-recaptcha 1.2.1, and login-hcaptcha 1.3.0.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-113667"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-44qr-rrjg-2cqq</id>
    <title>GHSA-44qr-rrjg-2cqq — ApostropheCMS: CAPTCHA response token not URL-encoded</title>
    <updated>2026-10-21T20:27:30.080047+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: @apostrophecms/form, npm: @apostrophecms/login-recaptcha, npm: @apostrophecms/login-hcaptcha</p>
<p>**Summary**
Form and login CAPTCHA verification interpolate the user-supplied widget token unencoded into the server-side verification URL/body, allowing a crafted token to inject query parameters into the reCAPTCHA/hCaptcha verify request.</p>
<p>**Details**
- `packages/form/lib/recaptcha.js:39` — `recaptchaUri = 'https://www.google.com/recaptcha/api/siteverify?secret=${recaptchaSecret}&amp;response=${input.recaptcha}'`
- `packages/login-recaptcha/index.js:44` — same pattern for login
- `packages/login-hcaptcha/index.js:47` — `body: 'response=${token}&amp;secret=${secret}'`</p>
<p>**PoC**
```
input.recaptcha = 'attacker_token&amp;secret=INJECTED_SECRET&amp;something=1'
→ resulting verify URL:
   https://www.google.com/recaptcha/api/siteverify?secret=&lt;real&gt;&amp;response=attacker_token&amp;secret=INJECTED_SECRET&amp;something=1
# (replicated exactly from recaptcha.js:39)
```</p>
<p>**Impact**
Low: a crafted token smuggles extra `key=value` pairs (`secret`, extra `response`) into the outbound verify call, forcing verification failures (DoS of the captcha gate and of captcha-gated login/form flows) and enabling automated bypass probing; no secret exfiltration.</p>
<p>**Remediation** — Build the verify request with `URL` + `searchParams` (or `encodeURIComponent` on both `secret` and `response`), and validate the token against `^[A-Za-z0-9._-]{1,2048}$` before use.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-44qr-rrjg-2cqq"/>
  </entry>
</feed>
