Where
-Infinity
0

Fabian Keil <freebsd-listen () fabiankeil de> wrote on 2026-05-18 at 10:02:48: Fabian Keil <freebsd-listen () fabiankeil de> wrote on 2021-01-31 at 13:13:29: Nick Tait <ntait () redhat com> wrote on 2020-12-23: That is a rather poor experience Fabian, sorry! Took a look at that incident number and no encrypted message appears on our end. I believe you did actually send a message but not sure what went wrong. While I can't directly help, did request the appropriate people follow up with you. Thanks a lot for your help, Nick.

I was contacted by someone from Red Hat Product Security on 2020-12-24 and received a CVE.

I replied and requested CVEs for the other issues fixed in Privoxy 3.0.29 but did not receive a reply yet. I just forwarded the request to <secalert () redhat com>. Privoxy 4.2.0, which is supposed to be released around 2026-05-30, will contain fixes for two security issues that are currently tracked as OVE-20260515-0001 and OVE-20260515-0002. The patches have been pushed to git today ([1], [2]).

The official Privoxy 4.2.0 release will probably happen tomorrow.

Quoting relevant parts of the preliminary announcement at [3] which I'll have to modify before the release as the reporter responded today:

| Privoxy 4.2.0 fixes a couple of bugs including two reported security | issues and brings a couple of general improvements including support | for elliptic-curve keys. | | Unfortunately the reporter of the alleged security issues did not | answer questions about the report that was based on an unofficial git | mirror which was apparently two years behind. CVEs have been requested | but haven't been assigned in time for the release. | | - Security fixes: | - Parse the chunk-size with a dedicated function and reject "unreasonably" | large values to prevent silent truncation by sscanf(), integer overflows | and misinterpretation of the content later on. Heap buffer overflows on | platforms with 32-bit pointers were alleged as well. | Commit 5b3bb22b77. OVE-20260515-0002. Reported by @TristanInSec. | - sslsendcertificateerror(): Store the generated message on the heap | instead of the stack to prevent an alleged segmentation fault if there | are enough certificates in the chain to exceed the stack size. | While at it, replace another variable-length array that was probably | unproblematic with a heap-based buffer as well. | Commit 4963aa4f08. OVE-20260515-0001. Reported by @TristanInSec.

While it wouldn't have helped here, I've also added two paragraphs to the "Reporting security problems" section [4] in the Privoxy documentation that request that use of "AI" is disclosed by reporters and that reporters should be prepared to respond to questions about their reports ... I tried to get two CVEs from Redhat yesterday by sending an encrypted mail to the address above, which is still listed at [0], but so far only received what looks like an automated response which claims that I need an "Atlassian" account to "finish" the request.

For various reasons I don't want an "Atlassian" or any other account ... I've sent a follow-up message to request a non-automated response on 2026-05-26 and received another obviously-automated response a bit later from "Atlassian <noreply+[...]@id.atlassian.com>".

This seems to contradict [0] which claims: | Only members of Red Hat Product Security, a restricted and carefully | chosen group of Red Hat employees, will have access to material sent | to the secalert () redhat com address. No outside users can subscribe to | this list.

Fabian

[0]: <https://access.redhat.com/security/team/contact/> [1]: <https://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff;h=4963aa4f08a378d0ea8a89433a95c3948a14bb9e> [2]: <https://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff;h=5b3bb22b771c93adddf1726ec904c9378d584a66> [3]: <https://www.privoxy.org/gitweb/?p=privoxy.git;a=blobplain;f=doc/webserver/announce.txt;hb=c93c69df8ff0b22e6d0a1bc02d7ce170e850cf02> [4]: <https://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff;h=84a1158f288df545ee45ed9326ccf984a360d4c7>

Fabian Keil <freebsd-listen () fabiankeil de> wrote on 2021-01-31 at 13:13:29: Nick Tait <ntait () redhat com> wrote on 2020-12-23: That is a rather poor experience Fabian, sorry! Took a look at that incident number and no encrypted message appears on our end. I believe you did actually send a message but not sure what went wrong. While I can't directly help, did request the appropriate people follow up with you. Thanks a lot for your help, Nick.

I was contacted by someone from Red Hat Product Security on 2020-12-24 and received a CVE.

I replied and requested CVEs for the other issues fixed in Privoxy 3.0.29 but did not receive a reply yet. I just forwarded the request to <secalert () redhat com>. Privoxy 4.2.0, which is supposed to be released around 2026-05-30, will contain fixes for two security issues that are currently tracked as OVE-20260515-0001 and OVE-20260515-0002.

I tried to get two CVEs from Redhat yesterday by sending an encrypted mail to the address above, which is still listed at [0], but so far only received what looks like an automated response which claims that I need an "Atlassian" account to "finish" the request.

For various reasons I don't want an "Atlassian" or any other account ...

Fabian

[0]: <https://access.redhat.com/security/team/contact/>

Severity
5
AV:N/AC:L/Au:N/C:N/I:N/A:P

Privoxy before 3.0.22 allows remote attackers to cause a denial of service (file descriptor consumption) via unspecified vectors. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203