सुरक्षा घटना विश्लेषण (पोस्ट-मॉर्टम) —— इंजीनियरिंग टीमों के लिए मूल कारण विश्लेषण और सुरक्षा ब्लूप्रिंट।
flawopen.com/घटनाएं (Incidents)/PostgreSQL CVE-2025-1094
CVE-2025-1094: जब सुरक्षा के लिए बना एस्केपिंग फ़ंक्शन ही सुरक्षा भेद्यता बन गया
सरल भाषा में समझें (ELI5)
कल्पना कीजिए कि एक अनुवादक का काम आपके बोले हर शब्द को उद्धरण चिह्नों (quotes) में बंद करना है ताकि कोई उसे आदेश न समझ ले। किसी को पता चलता है कि यदि आप किसी अनजान लिपि का शब्द बोलते हैं, तो वह भ्रमित होकर अंतिम उद्धरण चिह्न लगाना भूल जाता है। आपकी कही बात उद्धरण से बाहर आकर सीधे सिस्टम का आदेश बन जाती है।
The lessons that actually transfer
- ✓Parameterised queries are structurally safer than escaping, not just stylistically. A bound parameter travels to the server separately from the query text, so there is no quoting step that can be tricked. Escaping is a correctness problem someone has to solve perfectly, every time, for every encoding; parameterisation removes the problem.
- ✓Do not use an interactive CLI as a programmatic database driver. psql is a human tool with human conveniences like meta-commands. Piping application data through it imports those conveniences as an attack surface. Use the language's real client library.
- ✓Encoding validation belongs at the boundary. Reject input that is not well-formed in its declared encoding before it reaches any parser or escaper. A great many quoting and canonicalisation bugs begin with a byte sequence that should never have been accepted in the first place.
- ✓Patch your client libraries, not just the server. This was a flaw in libpq and psql — the client side. Teams that only tracked their PostgreSQL server version would have missed it.
- ✓Treat privileged-access vendors as part of your attack surface. Remote support and PAM tooling holds the keys by design. Its compromise is a direct route into every environment it serves.
FAQ
Does this mean escaping functions can't be trusted?
It means they are ordinary software with ordinary bugs, and that relying on them puts a correctness burden in a place where a single mistake is exploitable. Parameterised queries avoid the burden entirely, which is why they remain the primary recommendation.
Was my application vulnerable if I use an ORM?
Most ORMs and modern drivers use the extended query protocol with bound parameters rather than libpq's escaping helpers, which sidesteps the flaw. The exposure was concentrated in code that explicitly called the escape functions or shelled out to psql. Patching the client library is still the correct action.
Which versions fixed it?
PostgreSQL 17.3, 16.7, 15.11, 14.16 and 13.19, released on 13 February 2025.
Related reading
स्रोत और आधिकारिक एडवाइजरी