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/>

An XSS vulnerability was found in Privoxy which was fixed in cgierrornotemplate() by encode the template name when Privoxy is configured to servce the user-manual itself.

A memory leak vulnerability was found in Privoxy when handling errors.

A vulnerability was found in Privoxy which was fixed in geturlspecparam() by freeing memory of compiled pattern spec before bailing.

A vulnerability was found in Privoxy which was fixed in processencryptedrequestheaders() by freeing header memory when failing to get the request destination.

A flaw was found in privoxy before 3.0.32. Invalid memory access with an invalid pattern passed to pcrecompile() may lead to denial of service.

A flaw was found in privoxy before 3.0.32. A invalid read of size two may occur in chunkedbodyiscomplete() leading to denial of service.

A flaw was found in privoxy before 3.0.32. A crash may occur due a NULL-pointer dereference when the socks server misbehaves.

A flaw was found in privoxy before 3.0.32. A crash can occur via a crafted CGI request if Privoxy is toggled off.

A flaw was found in privoxy before 3.0.32. An assertion failure could be triggered with a crafted CGI request leading to server crash.

A flaw was found in Privoxy in versions before 3.0.29. Memory leaks when a response is buffered and the buffer limit is reached or Privoxy is running out of memory can lead to a system crash.

A flaw was found in Privoxy in versions before 3.0.29. Memory leaks in the show-status CGI handler when memory allocations fail can lead to a system crash.

A flaw was found in Privoxy in versions before 3.0.29. Memory leaks in the client-tags CGI handler when client tags are configured and memory allocations fail can lead to a system crash.

A flaw was found in Privoxy in versions before 3.0.29. Dereference of a NULL-pointer that could result in a crash if accept-intercepted-requests was enabled, Privoxy failed to get the request destination from the Host header and a memory allocation failed.

A flaw was found in Privoxy in versions before 3.0.29. Memory leak if multiple filters are executed and the last one is skipped due to a pcre error leading to a system crash.

A flaw was found in Privoxy in versions before 3.0.29. Memory leak when client tags are active can cause a system crash.

A flaw was found in Privoxy in versions before 3.0.29. Memory leak in the show-status CGI handler when no filter files are configured can lead to a system crash.

A memory leak vulnerability was found in Privoxy before 3.0.29 in the show-status CGI handler when no action files are configured.

A flaw was found in privoxy before version 3.0.31. A memory leak when decompression fails "unexpectedly" may lead to denial of service.

References:

https://www.openwall.com/lists/oss-security/2021/01/31/2

A flaw was found in privoxy before version 3.0.31. An assertion failure triggered by a crafted CGI request may lead to denial of service.

References:

https://www.openwall.com/lists/oss-security/2021/01/31/2

UNIX Symbolic Link (Symlink) Following vulnerability in the packaging of privoxy on openSUSE Leap 15.1, Factory allows local attackers to escalate from user privoxy to root. This issue affects: openSUSE Leap 15.1 privoxy version 3.0.28-lp151.1.1 and prior versions. openSUSE Factory privoxy version 3.0.28-2.1 and prior versions.

The clienthost function in parsers.c in Privoxy before 3.0.24 allows remote attackers to cause a denial of service (invalid read and crash) via an empty HTTP Host header.

The removechunkedtransfercoding function in filters.c in Privoxy before 3.0.24 allows remote attackers to cause a denial of service (invalid read and crash) via crafted chunk-encoded content.

Multiple use-after-free vulnerabilities in Privoxy before 3.0.22 allow remote attackers to have unspecified impact via vectors related to (1) the unmap function in list.c or (2) "two additional unconfirmed use-after-free complaints made by Coverity scan." NOTE: some of these details are obtained from third party information.

parsers.c in Privoxy before 3.0.23 allows remote attackers to cause a denial of service (invalid read and crash) via vectors related to an HTTP time header.

jcc.c in Privoxy before 3.0.23 allows remote attackers to cause a denial of service (abort) via a crafted chunk-encoded body.

Multiple unspecified vulnerabilities in pcrs.c in Privoxy before 3.0.23 allow remote attackers to cause a denial of service (segmentation fault or memory consumption) via unspecified vectors.

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.

Memory leak in the rfc2553connectto function in jbsocket.c in Privoxy before 3.0.22 allows remote attackers to cause a denial of service (memory consumption) via a large number of requests that are rejected because the socket limit is reached.