![[0x0v1]](https://www.0x0v1.com/content/images/2023/09/0x0v1-1.png)
Executive Summary
This research reveals several critical vulnerabilities in the WhatToExpect application, exposing users’ sensitive personal and reproductive health information to potential misuse and unauthorized access. These issues include an easily exploitable password reset mechanism that could lead to full account takeovers, an API that overexposes Personally Identifiable Information (PII) without sufficient access controls, and a vulnerability that allows the harvesting of group admin email addresses, including those in sensitive forums like Abortion Rights.
These vulnerabilities not only pose a risk to the broader user base but are especially concerning in areas where reproductive rights are under scrutiny. Beyond the United States—where abortion rights are a highly polarized issue—countries like Poland, El Salvador, Nicaragua, and the Philippines have stringent or total abortion bans, often criminalizing abortion without exceptions for rape, incest, or threats to the mother’s health. In these environments, exposure of reproductive health information could have severe consequences, leaving users vulnerable to harassment, doxing, incrimination, or even targeted attacks by malicious actors.
Attempts to responsibly disclose these issues to WhatToExpect went unanswered, highlighting a concerning lack of action by the organization to address serious security flaws. While reverse engineering is restricted by the app’s terms of service, my work is legally protected under laws permitting security research to identify and report privacy risks. The organization’s inaction raises significant ethical concerns about its commitment to safeguarding user privacy and security. This research aims to bring awareness to these vulnerabilities, emphasizing the critical importance of digital rights and user protection in applications that handle sensitive personal data.
Introduction & vulnerabilities
As part of my RE:privacy project, I have been reverse engineering reproductive health applications to uncover privacy and security concerns. The work that I've done so far has uncovered many issues in these applications, some of which are documented on the introduction page to the project.
Mozilla Foundation's Privacy Not Included work highlights a number of applications focused on Menstrual, Ovulation & Pregnancy tracking. With the rising issues of incessant capital making commodities out of data, the fact that we see these organizations profiting off such data is alarming. Particularly with the surrounding issues in United States regarding abortion rights.
The What to Expect Pregnancy Tracker & Baby App, rated as a "Privacy Not Included" product by Mozilla Foundation, is one such app that frivilantly shares and sells data from it's users. Owned by Everyday Health, they simply overtly state that they will sell data from it's users.
They can take your data and gather more data on you from sources like social media, public sources, and data brokers to build an even bigger profile on you with all your data. They say they they can use that data for lots of personalization and targeted marketing and advertising to try and sell you more goods and services. It seems there is a whole lot of money to be made using the personal information of pregnant women and expecting families. Which makes sense when they say they can collect a whole lot of your personal information --everything from your name, email, phone number to your due date, gender of your baby, education, work experience, precise location, browsing history, views and opinions, photographs, and much more. Yikes! - Mozilla Foundation
During my adventures in this application, I found the following vulnerabilities in the product:
- Remote access full account takeover vulnerability (CWE-640)
This is the most critical issue. There’s an exposed API endpoint that doesn’t require authentication and has no rate limiting. This any attacker trivially initiate a password reset request and then brute-force the reset code. There are a number of system weaknesses that make up this vulnerability:
- WhatToExpect's (WTE) reset code is 6 digits & has a time limit of 1 hour, which is extremely excessive.
- WTE does not validate any requests being made to the API to make a validation code attempt e.g IP validation, authentication etc.
- WTE's reset code mechanism has no rate limiting, meaning an attacker can make hundreds of thousands of requests to the API to reset a code without the system stopping them.
The reset code lifetime exists for an overzealous amount of time, 1 hour, which provides plenty of opportunity for an attacker to brute force it. To brute force such a code in 1 hour, is entirely feasible with a modern consumer CPU. If an attacker leveraged a GPU, it would be trivial—using an NVIDIA V100, the brute-force process could be completed in around 5 minutes, if not less.
A malicious actor could take over someone’s account and access potentially sensitive data. For example, if a woman had an abortion and they entered that information into the app, someone could easily retrieve it after taking over the account using this vulnerability.
- PII exposure and mishandling
There’s a serious PII issue with how they store and expose user data. With a valid User ID and JWT (obtained via a MITM attack or data leak), I found an API endpoint that overexposes PII. This includes the user’s name, address, IP address, user ID, age group, and reproductive data such as baby information (baby identifiers, if they lost a baby, etc.).
While the attack requires both the User ID and JWT, making it moderately complex, it’s still feasible. Though, the primary issue here is that PII is being returned with insufficient security controls, significantly increasing the risk of exposure.
Fundamentally, the API over-shares PII data that isn’t necessary for the operation which is a crucial privacy concenrn. Additionally, PII is stored in plain text, meaning there’s no encryption in place for data at rest, I think this is major issue and demonstrates that the organization may be breaching further laws in their back-end systems. With such sensitive data at risk, we should see symmetric encryption algorithms (e.g., AES) being used to encrypt and decrypt this data. This would ensure the data is encrypted at rest at minimum. I believe this to be a serious case of data mishandling.
They should also have stronger access controls such as MFA or RBAC to secure access to this sensitive data. Lastly, the JWT has an expiration time of 1 day, which is too long and increases the risk if compromised.
- Group admin email exposure
A smaller but still concerning issue: the API is exposing the email addresses of all group admins in the forum. This is particularly problematic for sensitive groups, like the Abortion Rights forum. It poses a serious privacy risk, increasing the chances of targeted harassment or attack.
The above provides a high-level summary of the issues found in this app, highlighting critical vulnerabilities to protect its users. I first attempted to communicate these issues to WhatToExpect on October 24, 2024, but received no response. On October 28, I escalated the issue to their PR team, but again, no response was given. After several attempts to report these vulnerabilities, it’s evident that WhatToExpect has been unwilling to address these security concerns in their product.
In working with journalists over at 404Media, who are covering this story, they attempted also to reach out to WTE for a comment. They received no communication back from the organization.
Responsible disclosure is a fundamental practice in ethical hacking, designed to protect users by informing app owners of security and privacy vulnerabilities. Typically, security researchers follow a process of privately disclosing these issues, giving developers the opportunity to resolve them before public disclosure. However, when app owners are unresponsive or unwilling to take action, the timeline for disclosure may be shortened to prioritize user safety. When security risks expose users to potential harm—such as unauthorized access to sensitive data or privacy breaches—it becomes essential to inform users or the broader security community. This approach balances the ethical obligation to protect end-users with the need to hold application owners accountable for securing their platforms. In this case, my goal is to ensure that users are aware of potential risks, especially given the silence from the app owners, and to encourage a swift resolution to safeguard personal data and maintain user trust.
As mentioned in the introduction to this project, this work is entirely self-funded as an independent researcher. I’ve spent weeks examining the security and privacy issues within WhatToExpect, without compensation or acknowledgment from the organization. This makes sustaining projects like this challenging. To support this work, the technical details of this report will be included below but limited to paid subscribers of my site. If you are a researcher, journalists, civic-society group or individual that requires access to the technical detail, I'm happy to provide this, please contact me.
For those browsing and interested in the technical breakdown, by subscribing, you gain access to all my technical reports, past and future, my newsletter, chat room and directly support digital and human rights through independent research into critical security and privacy issues. In the coming weeks/months, I also have three additional reports planned on other products, which will likewise be accessible to subscribers.
To clarify, no unauthorized access to WhatToExpect’s systems was taken at any point in this research, meaning that all actions were conducted legally without breaching any laws. Although their terms of service state that reverse engineering is not permitted, the law allows exceptions for security and privacy research, thereby protecting my work as legal under these provisions. Any DMCA takedown requests will be carefully reviewed in accordance with these regulations to ensure compliance with security research allowances.
If you would like to support this work through a one-time donation, please use the link below. Access to this report will be granted to donors as well—please contact me for access details.
Ovi
Donation Link
The technical breakdown follows below.