3 ms·

"if you have a software system that contains two different implementations of IDNA 2003 processing user input" Is that a real thing though? Is someone doing th

"if you have a software system that contains two different implementations of IDNA 2003 processing user input" Is that a real thing though? Is someone doing that?

gchamonlive 1mo ago
It isn't until it is, until during a crunch someone adds a package with that condition and eventually that gets exploited or halts the system. It's never a nitpick to shed your system from undesired state because of how complex systems behave.
kccqzy 1mo ago
It could be an implementation written in the buggy Python and another written in a different language. For example you might use a ready-made WAF written in a non-Python language in front of a Python app.
rcxdude 1mo ago
With web applications it's not particularly unusual, because the whole system stack can be quite heterogeneous. If one part of the system is doing authentication and the other part is actually doing the action then it can be a real problem when they interpret the input differently. Differences between proxy and web server interpretations of HTTP headers have been a source of multiple vulnerabilities, for example.
- dmurray 1mo ago
  It's not particularly unusual in Python, because it's normal that important functionality is implemented in other languages by a diverse set of third parties. That said, this isn't a security vulnerability, it's just a bug. To meet a reasonable threshold for being a security issue, you need to show a real system that has an issue caused by this, and then the vulnerability is in that system, rather than in Python. I'll grudgingly allow that a buffer overflow or an SQL injection possibility - in a library advertised as safe against that kind of bug - is a security issue, because there's so much history of turning those into real exploits. But a choice of library or language that makes those bugs easier to write - the idna library, or C or PHP say, is not itself a security issue.
  - shakna 1mo ago
    It's not unusual for this sort of string confusion to turn into an SSRF CVE [0]. [0] https://nvd.nist.gov/vuln/detail/CVE-2026-16221 https://nvd.nist.gov/vuln/detail/CVE-2026-16221
cwillu 1mo ago
Consider the case where your system has components in python and another language without the bug, both of which process that input.

"if you have a software system that contains two different implementations of IDNA 2003 processing user input" Is that a real thing though? Is someone doing that?

gchamonlive 1mo ago

It isn't until it is, until during a crunch someone adds a package with that condition and eventually that gets exploited or halts the system. It's never a nitpick to shed your system from undesired state because of how complex systems behave.

kccqzy 1mo ago

It could be an implementation written in the buggy Python and another written in a different language. For example you might use a ready-made WAF written in a non-Python language in front of a Python app.

rcxdude 1mo ago

With web applications it's not particularly unusual, because the whole system stack can be quite heterogeneous. If one part of the system is doing authentication and the other part is actually doing the action then it can be a real problem when they interpret the input differently. Differences between proxy and web server interpretations of HTTP headers have been a source of multiple vulnerabilities, for example.

dmurray 1mo ago
It's not particularly unusual in Python, because it's normal that important functionality is implemented in other languages by a diverse set of third parties. That said, this isn't a security vulnerability, it's just a bug. To meet a reasonable threshold for being a security issue, you need to show a real system that has an issue caused by this, and then the vulnerability is in that system, rather than in Python. I'll grudgingly allow that a buffer overflow or an SQL injection possibility - in a library advertised as safe against that kind of bug - is a security issue, because there's so much history of turning those into real exploits. But a choice of library or language that makes those bugs easier to write - the idna library, or C or PHP say, is not itself a security issue.
- shakna 1mo ago
  It's not unusual for this sort of string confusion to turn into an SSRF CVE [0]. [0] https://nvd.nist.gov/vuln/detail/CVE-2026-16221 https://nvd.nist.gov/vuln/detail/CVE-2026-16221

cwillu 1mo ago

Consider the case where your system has components in python and another language without the bug, both of which process that input.