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 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 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. Memory leak when client tags are active can cause a system crash.

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.

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

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.

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.

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 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 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 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. An assertion failure could be triggered with a crafted CGI request leading to server crash.

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. Invalid memory access with an invalid pattern passed to pcrecompile() may lead to denial of service.

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.

Privoxy before 3.0.21 does not properly handle Proxy-Authenticate and Proxy-Authorization headers in the client-server data stream, which makes it easier for remote HTTP servers to spoof the intended proxy service via a 407 (aka Proxy Authentication Required) HTTP status code.

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.

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