InstagramPrivSniffer: reading private account posts through a documented API behaviour

The disclosure timeline is the real story

Before describing what the tool does, the timeline in the disclaimer deserves attention, because it changes what the project is.

The dates are given plainly. Date reported: 29/06/2025. Meta replied: 01/07/2025. Tool created: 09/07/2025.

So the researcher found something, reported it to Meta, Meta answered within two days, and the tool was written eight days after the reply. The reason the tool exists is not that nobody noticed.

The finding is described as an endpoint that allowed viewing posts from a private Instagram account revealed via collaborating with public accounts. It was reported to Meta as a privacy issue, and after a few days Meta confirmed that this is intended behavior based on the Collaboration feature, and therefore this is not a vulnerability.

That last sentence is the important one. The project is not a zero day and it is not an exploit. It exercises a platform behaviour that the platform owner has explicitly confirmed as intended, which means the work is characterisation rather than exploitation. The proof of concept screenshot is in the repository under the assets directory.

What that does not mean is that the behaviour is harmless. Instagram's terms of service are a separate question from whether a behaviour is a vulnerability, and a tool that retrieves content from a private account will sit in an uncomfortable space with platform policy even when the platform's security team calls the behaviour intended.

The tool's own framing is conservative. It says it was created strictly for educational, research and digital investigation purposes, and that the developer is not responsible for any misuse. For any legal concerns regarding this project, contact the developer directly before taking any action, with the pointer to the issues guide in the contributing document.

The features list is short and states the intent plainly. It can assist digital investigators and cyber units to access private account posts which are revealed via collaborating with a public account, and it can download and view media.

The install is a standard Python virtual environment

The installation is the conventional four steps for a small Python script, and the documentation is explicit about the platform difference in two of them.

First, get the source, either by cloning the repository, which is marked as recommended:

git clone https://github.com/obitouka/InstagramPrivSniffer.git
cd InstagramPrivSniffer

or by downloading the ZIP archive and extracting it.

Second, create a virtual environment. On Linux and macOS that is `python3 -m venv.venv`, and on Windows it is `python -m venv.venv`.

Third, activate it, with `source.venv/bin/activate` on Linux and macOS and `.venv\Scripts\activate` on Windows.

Fourth, install the dependencies:

python -m pip install -r requirements.txt

The dependency list is remarkably short, and the two entries tell you what the tool actually does. `curl_cffi` at 0.14.0 and `requests` at 2.34.2.

The presence of curl_cffi alongside requests is the interesting one.

So the implementation is a small script over two HTTP clients, and the `requests` dependency covers the parts where a conventional client is enough.

The repository layout supports that reading. There is a `main.py` at the root, a `core/` directory, a `lib/` directory, a `utils/` directory and an `InstaDownloads/` directory, which is where the downloaded media lands. The `assets/` directory holds the logo, the sample screenshot and the proof of concept images.

Two commands, and one deliberate limit

The usage section is two commands and a note.

To see the available commands, navigate to the InstagramPrivSniffer root folder in a command line and run `python main.py -h`.

To test the tool, the author grants permission to test the command on their own experimental private Instagram account, @keyloggerluvr, as a proof that the tool works. To access the private account's post links, the command is `python main.py -n keyloggerluvr`. To download and view a specific post, it is `python main.py -d` followed by the post URL.

So the two modes are a name lookup and a URL download, which is the minimal surface for what the tool does.

The deliberate limit is the interesting design decision, and it is a good one. The author supplies their own account to demonstrate the tool, which means the demonstration is reproducible by anyone without the tool authorising them to look at a stranger's private account. Most tools in this space do not do that, because the demonstration usually involves a target who has not consented.

The requirement that shapes the tool is the collaboration relationship itself. The posts that become visible are the ones revealed via collaborating with a public account, which means the tool only has anything to fetch when that relationship already exists. It is not bypassing a privacy setting, it is reading content that a private account has chosen to expose to a public account, and Meta has confirmed that exposure is the intended behaviour of the feature.

That also explains the FAQ entry. The question is why there are no posts found even when the account has posts, and the answer is to refer to a specific issue in the tracker, issue 14. So the failure mode is known and documented rather than hidden, and the project points at the discussion rather than pretending the case cannot happen.

A repository shaped like a research disclosure, not a product

The repository layout and the surrounding metadata describe something closer to a published research artefact than to a maintained tool, and the details line up.

The top level is `main.py`, the `core/` directory holding the request logic, the `lib/` directory, the `utils/` directory and `InstaDownloads/`, which is where the fetched media is written. There is a `requirements.txt` with exactly two pinned dependencies, and a `LICENSE` file. The `.github/` directory holds the contributing document, and the README points at a specific section of it for the issues guide, so the project has an explicit policy for what to do with a question, a feature request and a bug report rather than leaving all three in one tracker.

The topic list on the repository places it under the awesome and awesome-cli and awesome-hacking and awesome-osint and awesome-python groupings, with a separate osint-tool and instagram-privsniffer tag, and the README carries a Category OSINT badge next to the MIT licence badge. The categories are the author's own framing and they are consistent with the disclaimer, which frames the tool as made for digital investigation and as something whose misuse is the reader's responsibility.

The version is 3.0.0, tagged on 2026-09-18, which is the only release in the list. A tool that began as a proof of concept after a disclosure can plausibly reach a 3.x version, since the numbering tracks the author's own iteration rather than a compatibility promise to a base.

The contact details are in the badge row as well, with a Telegram channel, a GitHub profile and a ProtonMail address, and the licence note adds that you are free to use, modify and distribute the project provided that you give credit and include the original copyright and license notice.

What is missing from the repository is as informative as what is in it. There is no test suite directory in the top level listing, no CI configuration beyond the `.github/` directory, and no changelog. For a project whose value is in a single technique rather than in a growing codebase, that is a reasonable shape, and it also means there is no automated signal when Instagram changes its behaviour. A user discovers that by running the tool and reading issue 14.

Where this tool stops, and what to think about before running it

There are four things to weigh, and none of them are about the code.

The first is scope. This is a single-account tool. It takes a name or a URL and it fetches what that one account has exposed. It is not a bulk collector, and the absence of that is a design property rather than a missing feature, since the whole point of the tool is to be usable for one investigation at a time without looking like mass targeting.

The second is the platform terms question. A behaviour being intended by the security team is not a grant of permission from the terms of service, and the two are different instruments. A researcher working under a legal instruction, with a documented scope and a reporting chain, is in a different position from a user running it because they want to see what a person posted. The project's own instruction to contact the developer for legal concerns before taking action is aimed at exactly this question.

The third is the fragile nature of the whole thing. The tool depends on an undocumented endpoint and on a platform that changes its client behaviour, and on TLS fingerprinting to keep the requests looking like a browser. All three are moving parts outside the repository. The dependency pins in requirements.txt give a fixed version for curl_cffi and requests, but they cannot pin Instagram's behaviour, and the FAQ's issue 14 is what that looks like in practice.

The fourth is what a reader should not do with it. The tool is for a case where you have a legitimate reason to look at a specific private account's exposed posts, such as an investigation you are authorised to run. It is not a way to look at someone's private account because you are curious, and the tool's own disclaimer says the developer is not responsible for misuse.

The alternative approaches are worth naming. Asking the account owner, or the public account they collaborate with, to share the posts, achieves the same goal with none of the fragility. And if the goal is to monitor an account over time, the API and the collaboration relationship are the wrong dependency, because a behaviour Instagram can change is a behaviour your tooling can lose overnight.

The project is MIT licensed, so the code is free to use, modify and distribute provided that you give credit and include the original copyright and license notice, and the copyright is held by obitouka for 2025.

Editorial conclusion

InstagramPrivSniffer fits a digital investigator who needs to see the posts of one specific private account that collaborates with a public account, because it turns a manual, slow walk through the web interface into two commands and gives you the media locally. Skip it if you need bulk collection, since the tool is built for a named account rather than for scraping at scale, and think carefully about the terms of the platform you are querying, because a documented API behaviour is not the same thing as permission. Before you rely on it, note that the tool needs a collaboration relationship to exist at all, and that the no posts found case has a known issue thread. The last push was on 2026-09-18 and the current release is v3.0.0.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. obitouka/InstagramPrivSniffer on GitHub
4. README
5. Releases