Pope’s Prayer App Leaks Data of 700,000+ Users

Key Takeaways

• The Click To Pray prayer app, endorsed by the Pope, exposed the personal data of over 700,000 users through an Insecure Direct Object Reference (IDOR) flaw.
• The API endpoint GET https://api.clicktopray.org/user/users/{id} returned any user’s profile when supplied with a sequential numeric ID, without any authorization check.
• Exposed information includes names, email addresses, dates of birth, country, and account‑deleted status—data that could be harvested en masse for phishing campaigns.
• The signup flow additionally leaked a validation hash that equals the UUID used in email verification links, allowing attackers to pre‑verify accounts before the legitimate confirmation email arrives.
• The real verification emails fail domain authentication, making them indistinguishable from spoofed phishing messages; attackers could send convincing emails with the same “none” authentication status as genuine communications.
• The vulnerability was reported to the Pope’s Worldwide Prayer Network six months prior to public disclosure, but no response or remediation has been received.
• Given the app’s user base—many older, less‑tech‑savvy individuals who trust Vatican‑associated services—the exposed data represents a significant phishing risk.

Overview of the Click To Pray App and Its Reach
Click To Pray is the official mobile and web application of the Pope’s Worldwide Prayer Network. Available in seven languages on iOS, Android, and via clicktopray.org, the app lets users worldwide submit prayers for the Holy Father’s intentions. As of July 2026, the service boasted 719,517 registered accounts, making it a sizable digital congregation. The app’s prominence and Vatican endorsement lend it a high level of trust among users, many of whom may be older individuals less familiar with online security nuances.

Discovery of the IDOR Vulnerability
Ethical hacker BobDaHacker identified a critical security flaw in the app’s backend on January 3. The vulnerability resides in an API endpoint designed to retrieve user profile information: GET https://api.clicktopray.org/user/users/{id}. By supplying any five‑digit numeric user ID, the server returns the corresponding account’s data without verifying whether the requester is the legitimate owner of that ID. This classic Insecure Direct Object Reference (IDOR) bug allows anyone to enumerate and harvest data simply by iterating through the sequential ID space.

What the Exposed Data Contains
Each request to the vulnerable endpoint returns a wealth of personal information: the user’s first and last name, email address, country of residence, date of birth, and a flag indicating whether the account has been marked as deleted. Because the IDs are sequential and there is no rate limiting, an attacker could automate a single GET request per ID (e.g., a simple Python loop) and scrape the entire database of 719,517 records in a short period. The dataset therefore represents a near‑complete snapshot of the app’s user base.

Why the Leak Is Particularly Dangerous
BobDaHacker emphasized that the exposed data is a “phishing goldmine.” Many Click To Pray users are likely older, devout Catholics who trust any communication bearing Vatican imagery or language. An attacker could craft an email that appears to come from “The Holy Father” urging urgent action, embed a Vatican‑styled link, and rely on the recipient’s trust to induce clicks. With legitimate‑looking names and email addresses in hand, such phishing attempts would have a high probability of success, potentially leading to credential theft, malware infection, or financial fraud.

Additional Flaw in the Signup and Verification Process
Beyond the IDOR issue, the signup endpoint (POST https://api.clicktopray.org/user/users/sign-up) returns a validation_hash directly in the response body. This hash is identical to the UUID used in the email verification link sent to the user’s inbox. Consequently, an attacker who creates an account with any email address can immediately obtain the verification token and confirm the account before the legitimate email even arrives, effectively bypassing the intended double‑opt‑in protection.

Authentication Problems with Legitimate Emails
Adding to the risk, BobDaHacker’s email client flagged the genuine verification messages from Click To Pray as failing the domain’s authentication checks (e.g., SPF/DKIM), labeling them as potential spoofs or improperly forwarded mail. Because the real emails already exhibit poor authentication, a malicious actor could send a pixel‑perfect phishing email that mirrors the legitimate message’s appearance and still pass (or fail) the same authentication checks, making it virtually impossible for recipients to discern the fraud from genuine communication based solely on technical indicators.

Lack of Response from the Pope’s Worldwide Prayer Network
The Register reached out to the Pope’s Worldwide Prayer Network for comment after the vulnerability was disclosed, but received no reply. BobDaHacker noted in her blog that she had reported the flaw six months earlier and still awaited a response, remarking wryly that “my email wasn’t in their prayers.” The silence suggests either unawareness, insufficient resources for remediation, or a delayed internal process, leaving the vulnerability live and exploitable at the time of writing.

Implications and Recommended Actions
The combination of an easily exploitable IDOR, leaked verification tokens, and poorly authenticated outgoing emails creates a multifaceted threat landscape. To mitigate risk, the Pope’s Worldwide Prayer Network should:

1. Immediately implement proper authorization checks on all user‑data endpoints, ensuring that a request can only access data belonging to the authenticated user.
2. Introduce rate limiting and anomaly detection on API calls to thwart enumeration attacks.
3. Regenerate and securely store verification tokens, never exposing them in API responses, and enforce email‑based verification before allowing any account activity.
4. Remediate domain authentication (SPF/DKIM/DMARC) for outgoing mail so legitimate messages can be distinguished from spoofed ones.
5. Notify affected users, advise them to monitor for suspicious communications, and consider forcing password resets or re‑verification of accounts.
6. Conduct a thorough security audit of the entire application, preferably with an independent third party, to uncover any additional weaknesses.

Until these steps are taken, the app remains a potent vector for large‑scale phishing and identity theft, undermining the very trust it seeks to foster among its global prayer community.