The One Hook That Never Got the Fix

I do a lot of my hunting by just reading source. No fuzzer, no live target, just the repo open in one window and a lot of scrolling. A couple of weeks ago I was doing that with NVIDIA’s Container Toolkit, and I found something I am still a little annoyed about. Annoyed in a good way.

The toolkit has a set of small helpers that run while a container is being created, and they run as root. At some point the project went through and hardened most of them so they resolve file paths safely inside the container root instead of trusting whatever the container image hands them. Good change. The kind you make once and apply everywhere. Except it was not applied everywhere. One hook got missed. I was reading through the others, watching the same safe pattern go by over and over, and then this one still did the old thing: take a path, look at it, change it, no checks. The image is supplied by whoever runs the container, so anything that hook touches is attacker influenced. A root level operation that trusts attacker input and reaches across the container boundary onto the host. That is the whole bug in one sentence.

I want to be honest about the limits, because they matter and because the report had them too. The hook is deprecated and off by default. It only runs if an operator went out of their way to switch it back on for an old workaround. When it does run, the operation is fixed, so this is not arbitrary anything and it is not code execution. I also did this as a pure source review. I read the code, I reasoned about the runtime, I built the primitive against the real binary, but I did not run the whole thing end to end on live infrastructure. I said all of that in the report. I would rather under claim and be trusted than oversell and get caught out.

I am not going to post the reproduction here. As of the 26th of June 2026 it still is not patched, so a step by step would just be a gift to the wrong people. The shape of it is enough for a writeup like this: one privileged hook, one missing safety fix, symlinks doing exactly what symlinks do.

I filed it on the 15th of June. On the 26th of June 2026 it came back as a duplicate. Medium, 6.0, zero dollars. Someone got there before me. And honestly, fine. No complaint about the dup. The finding was real, triage confirmed that much, and being early is not the same as being first. Whoever beat me to it did the same reading I did and sent it sooner. That happens. It is the game.

I did ask triage two things. One, whether NVIDIA does any kind of acknowledgment for a duplicate, hall of fame or a credit on the advisory, since the work was real even if it landed second. Two, since this is the one hook that never got the safety fix the rest of them already have, I offered to put the patch up upstream myself. I had already sketched it in the report. If it is being handled, great. If a pull request helps, I am happy to write it. Closing a real hole is worth more to me than a line on a leaderboard.

Here is what I am keeping from it. Reading source still works. The whole find came from noticing that one file did not match the pattern of its neighbors, and no tool was going to flag that for me. You read enough of the surrounding code to learn what normal looks like, and then the odd one out stands up and waves. Caveats are not weakness either. I spelled out every limit on this one, off by default, deprecated, source review only, and triage still took it seriously. Being straight about scope is what makes the rest of the report believable. And a duplicate is not a zero. The bounty was zero, sure. But I read a real codebase, found a real issue, wrote it up cleanly, and offered to fix it. That is the actual job. The payout is a side effect of doing it before someone else does.

On to the next file.