Example apps that ship vulnerable dependencies
Developer-tool companies publish example apps, starters and templates so that people can clone one and have something running in minutes. Many of those repositories commit a lockfile, so a fresh install reproduces exactly the versions that were current when the example was written. Months later, those versions have known critical vulnerabilities, and every new project started from the example inherits them. Measured between 12 and 15 October 2026.
How often it happens
We looked at the public example and template repositories of 12 funded developer-tool and AI-infrastructure companies (seed to Series B). Most were chosen because they publish many examples; two because we had already noticed one outdated example in their repositories, which is a bias towards finding problems. For each project with a dependency manifest, we took the versions resolved in its committed lockfile (or an exact pin when there is no lockfile) and compared the production dependencies with the GitHub Advisory Database.
| Companies | 12 |
|---|---|
| ... with at least one example resolving a critical advisory | 9 |
| Example projects checked | 517 |
| ... resolving a dependency with a critical advisory | 168 (32%) |
| ... with a high-severity advisory only | 34 |
Most of it is one dependency: Next.js. Starters pinned to 14.x, 15.x or early 16.x versions are affected by advisories such as GHSA-2xp9-vwfh-vxw4 (unauthenticated remote code execution in the Image Optimization API under certain configurations, fixed in 15.5.24 and 16.3.3). For examples still on 14.x there is no fixed 14.x release: the fix is a migration, not a one-line bump. The Python examples show the same pattern with exact pins in requirements.txt.
The repositories are not abandoned: several had commits in the same week. What drifts is the dependencies, because nobody owns them. Three of the twelve companies had no example resolving a critical advisory. In one of them we checked why: its templates do not commit lockfiles and use version ranges, so a fresh install picks up fixed releases.
Companies are not named
We report what we find to each company directly. This page gives the aggregate only.
Caveats
- An advisory affecting a version does not mean every app using it is exploitable: several Next.js advisories depend on configuration (image optimization settings, Windows hosting). The point is that people deploy these examples as they are, without checking.
- Only production dependencies, only high and critical advisories reviewed by GitHub, and only repositories we could identify as examples or templates. Development tooling is excluded.
- Without a lockfile or an exact pin, a project was not judged: a fresh install may resolve to a fixed version.
- A "project" is a directory with its own dependency manifest; a large example repository counts for many.
Keeping examples current
Bringing an example up to date takes one to two hours: bump the dependencies, regenerate the lockfiles, check that it still builds and type-checks, sometimes migrate a major version. Multiplied by dozens of examples, every time a new advisory lands, it is the kind of work that slips. We do it for teams: a catch-up pass with one tested pull request per repository, then a pull request within 48 hours whenever a new advisory or deprecation reaches one of your examples. Write to presendapp@gmail.com.
To check a single README, docs page or MCP configuration yourself, use the free install command check.