feat(cves): add CVE-2025-5947 - Service Finder Bookings Auth Bypass

[sedat4ras]

PR Information

• Added CVE-2025-5947 — Service Finder Bookings WordPress Plugin <= 6.0 Authentication Bypass via Cookie Spoofing
• References:
  • https://nvd.nist.gov/vuln/detail/CVE-2025-5947
  • https://patchstack.com/database/wordpress/plugin/sf-booking/vulnerability/wordpress-service-finder-bookings-plugin-6-0-authentication-bypass-via-user-switch-cookie-vulnerability
  • GHSA-x2xx-4qhp-2vqx
  • https://github.com/M4rgs/CVE-2025-5947_Exploit

Vulnerability Summary

The service_finder_switch_back() AJAX action in the Service Finder Bookings plugin fails to validate the original_user_id cookie before switching user context. An unauthenticated attacker can set Cookie: original_user_id=1 and call the action to gain admin-level access.

• CVSS: 9.8 (Critical)
• CWE: CWE-639 (Authorization Bypass Through User-Controlled Key)
• Affected: All versions <= 6.0
• Patched: Version 6.1 (released July 17, 2025)
• Actively exploited: 13,800+ attempts blocked by Wordfence on disclosure day

Template Logic

1. First request confirms the plugin is installed by checking readme.txt
2. Second request attempts the bypass: GET /wp-admin/admin-ajax.php?action=service_finder_switch_back with Cookie: original_user_id=1
3. Matches on a 301/302 redirect to wp-admin (not wp-login.php) indicating successful user context switch

Template validation

• Validated with a host running a vulnerable version and/or configuration (True Positive)
• Validated with a host running a patched version and/or configuration (avoid False Positive)

Note: I was unable to test against a live vulnerable instance. Happy to refine matchers with feedback from the team or community members who can verify against a real target.

Additional Details

• Shodan query: http.html:"sf-booking"
• PublicWWW query: /wp-content/plugins/sf-booking/

[neo-by-projectdiscovery-dev]

Neo - Nuclei Template Review

No security issues found

3 issues fixed in this PR

Hardening Notes

• The verified: true flag is still missing from metadata. As noted in PR description, author could not test against a live vulnerable instance. Community verification is needed before merging.
• Template was simplified from two-stage (plugin-check + exploit-check) to single-request approach. This may attempt the exploit on any WordPress site, but the specific matchers (Location header + session cookie) should prevent false positives.
• Removed CPE classification field and extractors section - these are optional enhancements but not required for template functionality.

_{Comment @pdneo help for available commands. · Open in Neo}

[sedat4ras]

Hi @DhiyaneshGeek,

Thanks for the review via Neo. Here's a quick update on the findings:

Fixed:

• ✅ Replaced broad header matcher with specific Location header regex: (?i)Location:.*\/wp-admin\/
• ✅ Added wordpress_logged_in_ cookie matcher for stronger authentication verification

Pending:

• verified: true — I don't have access to a live vulnerable instance (Service Finder Bookings ≤6.0). Happy to add this flag if someone from the community can verify, or if you'd like to test internally.

Let me know if any further changes are needed!

[theamanrawat]

Hi @sedat4ras,

Thank you so much for sharing this template with the community and contributing to this project 🍻

We tried to reproduce the POC, but it didn't work on our end. If you believe the template is correct, please send a vulnerable lab environment to templates@projectdiscovery.io.

[sedat4ras]

Hi @theamanrawat,

Thanks for testing! I think I found why reproduction failed.

Root cause: The wordpress_logged_in_ cookie matcher is likely causing a false negative. In this specific attack vector, the exploit works via cookie spoofing — the attacker sends original_user_id=1 in the request cookie, and service_finder_switch_back() switches the context without proper validation. WordPress then redirects to /wp-admin/ but does not necessarily set a new wordpress_logged_in_ session cookie in the response (since the session isn't being created fresh — the function just switches context and redirects).

So the matchers-condition: and is too strict: the third matcher (Set-Cookie check) will never match in this unauthenticated scenario, making the template always return a false negative on real targets.

Proposed fix: Remove the wordpress_logged_in_ matcher and rely on the 301/302 redirect to /wp-admin/ as the confirmation signal — consistent with how the PoC at https://github.com/M4rgs/CVE-2025-5947_Exploit works.

Would you like me to push this change? Happy to update the template if this aligns with your assessment.

[codeCraft-Ritik]

Excellent improvement