Good question! I wasn't too concerned about this, because the only way you could even interact with the OS where the server was running was via HTTP requests, which are fairly limited in nature. The OS or kernel itself wasn't directly exposed per se.
Am I missing something here? Colonial merchant ledgers and 18th-century accounting practices have been extensively digitized and discussed in academic literature. The model has almost certainly seen examples where these calculations are broken down or explained. It could be interpolating from similar training examples rather than "reasoning."
The author claims that they tried to avoid that: "[. . .] we had to choose them carefully and experiment to ensure that these documents were not already in the LLM training data (full disclosure: we can’t know for sure, but we took every reasonable precaution)."
> yep. no auth. just an email parameter. and what did it return?
> full names. emails. phone numbers. flight receipts. all just by passing an email address in a URL.
> i reported it through their security bounty program, made a bug fix pr (because apparently that's how you get things done around here), and maybe made the slight mistake of sharing the vulnerable endpoint in that group chat - which less than 10 people saw, for what that's worth.
The author then proceeds:
> their security bounty program states minimum payouts for this kind of thing start around $150. but exposing passport numbers (which are classed as government documents) should bump it up significantly. apparently "responsible disclosure" means "don't tell anyone, even in a private chat" so they docked the entire payout.
I'm not sure why they're being seemingly sarcastic about responsible disclosure. Yes, responsible disclosure absolutely means that you disclose this to the vendor before disclosing it to anyone else. As someone who works as a penetration tester and security researcher (both at work and in my free time), in my opinion, there should be no confusion about what responsible disclosure is. You disclosing the vulnerability in public before the vendor has had the chance to fix or apparently even triage it is not "responsible disclosure" or a "slight mistake".
I pentest network devices (amongst other things) for a living, and the way these usually work is that they have dnsmasq running in the background and to accept user config values, templating is used to generate dnsmasq-specific configuration files which are then fed into dnsmasq. I cannot overstate how common this method is.
Some devices do this more securely than others. If you're able to inject newlines, it's highly likely that you can already achieve command execution by injecting directives. I wrote a bit about this technique here: https://blog.nns.ee/2025/07/24/dnsmasq-injection-trick/ (sorry for the self-plug). I think it's up to the device vendor to do this securely and not a concern for dnsmasq.
However, in this case, I feel like the concern is elsewhere and not the sole responsibility of the device vendors. Even if the vendor does templating securely, the vulnerable config options could still trigger the bug in dnsmasq itself and give some advantage to the attacker. Assuming the vulnerabilities themselves are legit, I'm finding it difficult to classify these issues as "bogus".
exactly, that's what i thought. must be one of those: it was always done that way, or maybe just, the banks bought machines to print the cards from the US or where they still do that (do they actually?) or simply those machines were cheaper, or who cares, its not like there is a downside to embossing the numbers. it could also be estonians who fled to the US in the previous century returning and bringing back their idea of how it should be done.
i was visiting the baltics in the early 90s and i head that people were desperate to get anything from the west after being cut of for so long.
reply