Background
In April 2021, my daughter was born almost a month early and needed medical support. She was taken to the NICU, and the doctors told us she would most likely be there for around three weeks.
With only limited time off from work, I eventually had to go back. But the hospital had something that gave us peace of mind: a NICU camera system that let parents log in and see a live feed of their baby from anywhere. It was a lifeline for us.
Initial Discovery
Babies change so much in those early weeks, and I didn't want to miss it. I had the idea to capture a timelapse of my daughter during her NICU stay. So I started looking at how the camera feed worked.
The implementation appeared straightforward: the camera feed was effectively serving an updated image from a predictable URL. After copying the image URL to automate frame capture, the underlying access pattern became obvious.
Technical Finding
The camera feed URL followed a pattern like:
/180/10/camera.pngLoading the URL directly returned my daughter's feed as expected. The concern was that the numeric path segments appeared to be simple identifiers rather than values tied to an authorization check.
Changed /180/10/ to /180/2/
A completely different baby appeared.
Changed /180/ to a different number
The furniture and room style changed entirely — a different hospital.
The first number appeared to identify the hospital, while the second identified the camera within that facility. Authentication allowed access to the application, but the image endpoint itself did not appear to enforce object-level authorization. Modifying those identifiers allowed access to feeds belonging to other families and hospitals.
Exposure and Impact
This was far worse than just seeing anonymous video of babies. Depending on the camera angle and what was in frame, you could see:
- Live video feeds of newborns in NICUs across the country
- Cards displaying the baby's name and parents' names
- Medical information including medications and care notes
- Staff check-in logs showing who last attended the baby
- Hospital names visible in headers and signage
Any authenticated parent account with a browser could have accessed this information. No special tooling or privileged access was required; changing numeric identifiers in the URL was sufficient.
Vulnerability: Insecure Direct Object Reference (IDOR)
IDOR occurs when an application exposes internal object references — like database IDs or file paths — in a way that lets users manipulate them to access unauthorized resources. In this case, sequential camera and hospital IDs in the URL allowed authenticated users to access unauthorized camera feeds across the system.
Disclosure Timeline
I reported the issue immediately to the NICU at the hospital where my daughter was born and provided a screen recording showing reproducible access to other cameras by changing the identifiers in the URL.
- 0hVulnerability discovered and documented
~1hContacted hospital NICU with video demonstration
~2hNICU camera system taken completely offline
~48hPermissions fixed — service restored with proper access controls
Conclusion
I was not attempting to test the security of the system; I was simply trying to monitor my daughter while she was in the NICU. Even so, the issue made clear how dangerous predictable resource identifiers can be when object-level authorization is not enforced, especially in a system handling live NICU camera feeds and protected health information.
Responsible disclosure was the priority. To the vendor's credit, the response was fast: the service was taken offline within roughly two hours of the report, and proper controls were in place within 48 hours. The objective was not public blame, but rapid remediation for affected families.