A critical security flaw in the Vatican's Click to Pray application exposed the personal data of over 700,000 global users. This analysis highlights the technical details of the BOLA vulnerability, the registration hash leak, and practical steps to detect and prevent automated database harvesting.
Locate GET /user/users/{id} API endpoint
Loop predictable sequential user IDs (1-719517) without auth headers
Extract emails, names, birthdates, and roles with unthrottled HTTP scripts
Independent security researcher BobDaHacker identifies the unauthenticated API and IDOR vulnerabilities.
Vatican remediates the Click to Pray API access-control logic issues.
If your team may be exposed to a similar threat, FemtoSec can help validate blast radius, prioritize remediation, and connect the issue to a practical security program.
June 16, 2026
A threat actor has surfaced claiming to sell an exploit method for Windows Explorer, highlighting critical risks in endpoint security, persistent access, and the need for proactive defensive validation.
August 9, 2026
An underground threat actor is actively selling two unauthenticated SQL injection zero-day vulnerabilities affecting widely used MyBB plugins with over 20,000 downloads. Learn the technical mechanics of the threat, the attack chain, and actionable detection strategies to secure your forum infrastructure.
July 15, 2026
An active exploit code for CVE-2026-50656, a high-severity local privilege escalation flaw in the Microsoft Malware Protection Engine, is being sold on dark web forums. Learn how the RoguePlanet exploit works and how to protect your enterprise Windows systems.
Security teams auditing enterprise web applications and mobile backend architectures must immediately prioritize the validation of access-control logic, focusing specifically on detecting Broken Object Level Authorization (BOLA) flaws. These vulnerabilities serve as a friction-free pathway for automated threat scripts to systematically scrape sensitive user databases without raising traditional security alerts. Identifying these weaknesses before they are exposed to the public is the first line of defense for modern organizations. When web APIs do not enforce session isolation and object-level permission checks, they expose critical business assets to massive exfiltration. Proactive validation via specialized application testing is paramount to closing these exposure windows before threat actors capitalize on them.
The necessity of rigorous access-control auditing is highlighted by a significant security exposure that occurred within the Vatican's official prayer application, Click to Pray, hosted at clicktopray.org. The application, which is managed by the Pope's Worldwide Prayer Network and developed by La Machi Communication for Good Causes, suffered from a critical unauthenticated API vulnerability. This flaw exposed the personally identifiable information of 719,517 registered users worldwide. Independent security researcher BobDaHacker discovered the access-control flaw in January 2026, and the exposure remained active for nearly seven months before being completely remediated on July 24, 2026. The exposed data fields included user names, email addresses, country origins, dates of birth, account roles, and profile deletion indicators, presenting significant privacy risks and downstream identity threats for the affected global user base.
Analyzing this API compromise through the lens of the MITRE ATT&CK framework reveals several distinct techniques utilized during the automated harvesting process. The primary technique exploited was T1190 (Exploit Public-Facing Application), where the lack of authentication and object-level verification on the exposed API was leveraged to access internal database records. The massive extraction of user profiles maps directly to T1119 (Automated Collection), where simple HTTP scripts were used to systematically execute sequential queries without encountering lockouts or detection filters. Finally, the gathering of user directories falls under T1592.002 (Gather Victim Identity Information), providing threat actors with a verified repository of active email addresses and corresponding personal names that can be used to construct highly convincing phishing campaigns.
Ensuring that customer and employee domains have not been compromised through historical exposures or credential harvesting is a critical priority for enterprise defenders. If you suspect your domain or credentials have been exposed in recent public database leaks, immediate triage is necessary.
Free exposure check
Dark Web Scanner
check dark web mentions, compromised account indicators, malware log signals, public breach exposure, and recent underground market activity for your domain.
By integrating continuous offensive testing with proactive security assessments, enterprises can safeguard their applications from critical logical flaws and ensure absolute compliance with regional standards.
To understand how this data exposure occurred, security teams must examine the underlying architecture of the Click to Pray backend API, which was constructed using the Express framework on Node.js. The vulnerability stem from two distinct logical flaws in the application design. The first and most severe was a classic Insecure Direct Object Reference (IDOR) behavior, also recognized as Broken Object Level Authorization (BOLA). When users created profiles on the platform, the backend database assigned them sequential, predictable numeric identifiers starting from number 1 and reaching up to 719,517.
The application exposed a specific endpoint, GET https://api.clicktopray.org/user/users/{id}, to retrieve user profile data. However, the backend database query did not validate whether the client initiating the HTTP request possessed the authorization to view that specific user record, nor did it verify if the client was authenticated at all. Because of this complete lack of access checks, any unauthenticated client could supply arbitrary integers into the URL path parameter. An automated script could easily loop through every sequential identifier from 1 to 719,517, systematically pulling down individual database records. This lack of rate limiting and lack of identity validation turned a private user directory into a publicly accessible database.
The second critical design flaw involved the user registration and validation flow. When a new user registered on the application, the system would generate a unique email verification token, known as a validation hash, and send an email containing an activation link to the user's inbox. This mechanism is standard practice to confirm email ownership. However, instead of processing this validation hash strictly on the server or limiting its delivery to the outbound email transport, the Express Node.js backend returned the raw validation hash directly within the JSON response body of the signup API HTTP request.
This behavior created a serious account hijacking vector. An attacker could initiate a signup request using a target's email address. By intercepting the immediate API response payload using standard browser inspection tools or a local interception proxy, the attacker could extract the plaintext validation hash from the JSON response. This validation token could then be submitted to the confirmation endpoint, enabling the attacker to complete the registration and assume control of the account flow without ever having access to the victim's external email inbox. This logical bypass demonstrates the risk of returning sensitive state indicators to the client side.
The overall attack chain for this exposure can be categorized into three distinct phases. First, the initial access and discovery phase began when an unauthenticated client established a connection with the backend API domain. By analyzing the API traffic, the actor identified the structured user retrieval endpoint. Second, the execution phase utilized automated collection tools to query the sequential user IDs. Because the platform lacked active rate-limiting and query throttling, the script harvested thousands of records per minute. Third, the impact phase was realized as the harvested personal data, containing emails, names, birth dates, and country codes, was consolidated into a massive dataset suitable for secondary phishing, social engineering, and targeted credential attacks.
The exposure of user databases containing names, emails, and physical locations presents major operational and regulatory challenges for global organizations. In the GCC region, where digital transformation and mobile application adoption are accelerating rapidly, strict data residency laws and regulatory frameworks demand that personal data be secured with the highest standards of integrity. Organizations operating across the Gulf must recognize that unauthenticated APIs represent a critical compliance failure under frameworks such as the Saudi Personal Data Protection Law and the UAE Federal Decree-Law on Personal Data Protection. A data exposure of this scale can result in severe financial penalties, damage to brand trust, and operational disruption.
To address these risks, proactive organizations leverage advanced Penetration Testing to identify structural logic flaws in their applications before they are deployed to production. Continuous monitoring and defensive validation are essential to maintaining compliance and protecting user trust. Incorporating structured Vulnerability Assessments into the software development lifecycle ensures that security teams can catch API misconfigurations, unauthenticated routes, and hardcoded secrets early, establishing a robust and resilient security posture.
Defenders must establish concrete detection and containment capabilities to protect their API gateways from similar exploitation. Security operations center analysts can identify historical database scraping attempts by analyzing web server and API gateway access logs for specific behavior patterns. First, analysts must monitor for high-volume sequential requests originating from a single client IP address or user-agent directed at user query endpoints. A rule should flag any source initiating more than 100 requests per minute where the resource identifier is incrementing sequentially.
Second, analysts must monitor abnormal status code distributions. Automated scraping scripts targeting non-existent, deleted, or reserved account IDs will frequently trigger HTTP 404 (Not Found) or HTTP 500 (Internal Server Error) responses. A high ratio of error responses paired with successful HTTP 200 (OK) responses on administrative or user query paths is a strong indicator of active scanning. Additionally, security teams must audit API signup endpoints for abnormal country-of-origin patterns or high-frequency registration attempts from unified source addresses, which may indicate account creation abuse or token harvesting.
Security teams can actively validate whether their APIs are susceptible to BOLA or registration bypass using isolated testing protocols. To test for session isolation, an analyst should authenticate as two distinct test users, User A and User B. By capturing the legitimate profile retrieval HTTP request for User A and swapping the target identifier parameter to that of User B while keeping User A session headers intact, the tester can observe the server behavior. If the server yields User B private profile details, BOLA is confirmed. To validate unauthenticated access, the tester must replay the request with all authentication headers stripped completely. A successful response confirms the endpoint is public.
Remediating API access flaws requires a combination of secure coding standards, architectural adjustments, and gateway protections. Organizations should implement the following steps to secure their backends:
Enforce Object-Level Authorization: Ensure that every API route performing data retrieval validates the client identity and confirms that the session token has explicit authorization to access the specific resource identifier requested.
Implement Non-Sequential Identifiers: Replace auto-incremented database integers with cryptographically secure, random Universally Unique Identifiers (UUIDv4). This eliminates predictable numbering and prevents attackers from easily enumerating the database.
Restrict Response Payload Fields: Minimize the data returned in API response schemas. Sensitive properties, such as verification hashes, internal role markers, or system parameters, must never be returned to the client browser unless absolutely necessary.
Enforce Rate Limiting and WAF Policies: Deploy a Web Application Firewall (WAF) to throttle request volume based on IP addresses, API tokens, or session IDs, preventing bulk automated extraction of user records.
