Click To Pray, the Pope-endorsed prayer app with 719,517 registered accounts as of July 2026, has been leaking people’s names and email addresses for months, possibly longer, according to an ethical hacker who says she reported the issue and got no response. BobDaHacker, who has previously exposed security weaknesses in McDonald’s ordering system and open controls on Pudu Robotics, says she found the vulnerability six months before publication and disclosed it to the Pope’s Worldwide Prayer Network on January 3.

Her core claim is blunt: “The vulnerability is still live,” she wrote in a Friday blog. She also said that “Nobody has ever responded,” adding, “I guess my email wasn't in their prayers.” In other words, this isn’t a theoretical bug that got patched quietly. It is a live data leak that decision-makers should treat like an active incident, not a past compliance issue.

So what went wrong? The flaw is an Insecure Direct Object Reference (IDOR) issue. In plain English, that means the app’s API will hand over someone else’s records if you can guess or obtain the right identifier. As BobDaHacker explained, it is a common and easy-to-exploit pattern where an app “blindly accepts user-provided input to view or modify resources without checking to see if the user is actually authorized to retrieve the data.” Her illustration is the type of security failure that turns authorization into an illusion: “You ask for your own data, the server gives it to you. You ask for someone else's data, the server gives you that too. Thou shalt not authorize, apparently.”

The mechanism, per the disclosure, is tied to how Click To Pray assigns user IDs. When someone signs up for an account, the app gives them a sequential numeric user ID. BobDaHacker found that the API endpoint GET https://api.clicktopray.org/user/users/{id} returns user data for any account, not just the requester’s own, so long as the attacker supplies a valid, five-digit user ID. There is no ownership validation and no authorization check.

The data exposure is also specific. BobDaHacker says the API exposes users’ email addresses, first and last names, country, dates of birth, and whether the account has been deleted. And because the IDs are sequential, she argues there is a straightforward enumeration path: “With sequential user IDs and no rate limiting, an attacker could enumerate every single account on the platform.” Her described method is essentially one request per user, looping across the ID range, “That's it. That's the exploit.” In operational terms, that is the difference between a leak that might be limited to a handful of victims and one that can be scraped at scale.

The second-order consequence is not just personal data exposure. It is phishing economics. BobDaHacker frames the user base as particularly vulnerable to manipulation: many users are likely older individuals, not all that tech savvy, and likely to trust anything associated with Vatican-related communications. That is why she calls the exposed accounts a “phishing goldmine.” She gives a scenario: imagine receiving an email that says “The Holy Father requests your urgent attention” with a Vatican-looking link, and “Grandma is clicking that. Every time.” Even if your organization does not run email marketing campaigns, this is still a direct reminder that identity data plus brand trust becomes attack infrastructure.

Then the story gets worse, because the same weaknesses bleed into the app’s onboarding and email validation. BobDaHacker says the signup endpoint, POST https://api.clicktopray.org/user/users/sign-up, returns a validation_hash directly in the response body. She notes that this value is the same UUID used in the email verification link. Practically, that means an attacker could sign up using any email address and verify the account before the actual confirmation message arrives in the victim’s inbox.

There is also a signal that the emails themselves may not be authenticated the way a real verification flow should be. BobDaHacker says her email client flagged the real verification email with a warning that it had failed the domain’s authentication requirements and might have been spoofed or improperly forwarded. She links the dots: the API is leaking 700,000 email addresses for phishing, and the legitimate emails from Click To Pray already look like phishing. Her punchline is religious, but the control problem is the same: attackers do not have to “try hard” when your system’s output looks suspicious even before anyone weaponizes it.

The Register reached out to the Pope’s Worldwide Prayer Network and did not receive any response. The practical stakeholder question for executives, boards, and technical leaders is simple: how does a vulnerability that permits enumeration of 719,517 accounts stay live after it is reported, especially when the app’s mission is trust, prayer, and personal connection? For organizations that handle identity, email, and sensitive life events, this is a case study in what happens when basic authorization controls fail, rate limiting is absent, and remediation is not visibly executed. Peers in consumer apps, faith and community platforms, and any organization with a public-facing identity system should treat this as a reminder that privacy failures are often API failures, and API failures tend to scale faster than most incident response teams can comfortably react.