Port 3690 – SVN (Apache Subversion)

Port 3690 is the default port for the Subversion (SVN) svnserve version-control server, the daemon that speaks Apache Subversion’s native svn:// protocol. When a client runs svn checkout svn://host/repo, this is the port it connects to. Subversion can also be served over HTTP(S)/WebDAV through Apache’s mod_dav_svn on port 80 and port 443, and tunnelled over svn+ssh:// via SSH on port 22 — but 3690 is the bare, purpose-built svnserve listener, and it’s the one worth checking first because it so often gives up an organisation’s entire source history to anyone who asks.

Why It’s Open

Subversion was the dominant centralised version-control system for most of the 2000s, and while Git has largely replaced it, huge amounts of legacy code still live in SVN. You’ll find svnserve on internal developer boxes, build and CI servers, self-hosted forge appliances, and vendor gear that bundled a repository for firmware or configuration. It gets left exposed because it’s simple to stand up (svnserve -d -r /srv/svn) and because whoever set it up years ago is rarely the person running the network today. Where port 3690 is answering, the same repositories are often reachable over mod_dav_svn on 80/443 or via svn+ssh on 22 as well — worth scanning for.

Common Risks

• Anonymous read = source-code disclosure. Many svnserve setups ship with anon-access = read in svnserve.conf, so an unauthenticated attacker can svn checkout svn://host/repo and pull the entire source tree and its full revision history. That history routinely contains hardcoded credentials, API keys, database connection strings, and private config. This is the signature finding on port 3690.
• Deleted secrets still live in history. Removing a password in a later commit doesn’t remove it from SVN. svn log and older revisions expose anything ever committed, so “we already rotated that” is rarely true until the repo itself is retired.
• Weak, unencrypted authentication. svnserve’s built-in auth reads a cleartext passwd file and authenticates with CRAM-MD5 over the wire — brute-forceable and with no TLS on plain svn://. Credentials and repository contents cross the network in the clear; only svn+ssh (port 22) or HTTPS encrypts the session.
• Unintended write access. A misconfigured auth-access = write or a broad [groups] grant lets an attacker commit backdoors, poison build scripts, or tamper with released code.
• Exploitable svnserve builds. Older Subversion daemons carry pre-authentication memory-corruption bugs in the svn:// protocol parser (see the CVEs below) that turn an exposed port 3690 into remote code execution.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Detect the service and grab the version

nmap -sV -p 3690 <target>

Brute-force svnserve auth (CRAM-MD5)

nmap -p 3690 --script svn-brute --script-args svn-brute.repo=/repo <target>

Query the repository over svn://

svn info svn://<target>
svn ls svn://<target>/repo

Check whether anonymous access is allowed

# If this succeeds without credentials, anon-access is on
svn ls svn://<target>/repo
svn cat svn://<target>/repo/trunk/config.php

Pull the whole tree and mine the history

svn checkout svn://<target>/repo svn_dump
svn log -v svn://<target>/repo        # every commit, author, and message
svn cat -r 3 svn://<target>/repo/trunk/settings.py   # read an old revision

Grep the checkout for secrets

grep -rEi 'password|api[_-]?key|secret|BEGIN .*PRIVATE KEY|Authorization' svn_dump

Metasploit — svnserve date-parsing RCE (old builds)

msfconsole -q
use exploit/multi/svn/svnserve_date
set RHOSTS <target>
run

Record every open port 3690, every repository you can read, and every secret you recover as you go, so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

• CVE-2004-0397 — Stack buffer overflow in svnserve’s date parsing (get-dated-rev), in Subversion ≤ 1.0.2. Pre-authentication remote code execution over the svn:// protocol on port 3690 — it does not work against Subversion over WebDAV. Weaponised as Metasploit’s exploit/multi/svn/svnserve_date and archived on Exploit-DB. CVSS 7.5.
• CVE-2004-0413 — Integer overflow leading to a heap-based buffer overflow in the way libsvn_ra_svn handles the length prefix of svn:// strings, in Subversion ≤ 1.0.4. Remote code execution / DoS; the vulnerable parser is shared by svnserve and clients. CVSS 10.0.
• CVE-2015-5259 — Integer overflow in the read_string function in libsvn_ra_svn/marshal.c, in Subversion 1.9.0–1.9.2 (fixed in 1.9.3). A crafted svn:// protocol string triggers a heap overflow and out-of-bounds read, allowing code execution. Because the parser is shared, it affects both svnserve on 3690 and clients over svn:// / svn+ssh://. CVSS 8.6.
• CVE-2017-9800 — A maliciously constructed svn+ssh:// URL makes a Subversion client run an arbitrary shell command (clients before 1.8.19 and 1.9.x before 1.9.7). This is a client-side flaw tied to the svn+ssh transport over SSH (port 22), not svnserve itself — relevant when your own checkout scripts hit an attacker-controlled URL. CVSS 9.8.
• CVE-2020-17525 — NULL-pointer dereference in mod_authz_svn (before 1.10.7 / 1.14.1) that crashes the worker on requests for non-existent repository URLs. This affects mod_dav_svn over HTTP(S) on 80/443, not svnserve on 3690 — included here only to keep the two transports straight. Denial of service, CVSS 7.5.

Mitigation

• Don’t expose svnserve to the internet. Firewall TCP/3690 to a trusted management or developer range; a public svnserve is almost always a mistake.
• Disable anonymous access. Set anon-access = none and auth-access = write (or read) explicitly in svnserve.conf, and require authentication for every operation.
• Encrypt the transport. Prefer svn+ssh over SSH (port 22) or mod_dav_svn over HTTPS (port 443) with real authentication instead of plaintext svn://.
• Rotate every secret found in history. Assume anything ever committed is compromised; rotate credentials and keys, and purge them from the repo (e.g. dump/filter) rather than just deleting them in a new commit.
• Patch Subversion, or migrate off SVN entirely if the server is unmaintained — most modern teams move the history to Git.
• Restrict write paths with a per-path authz file so no single account can rewrite the whole tree.

Real-World Example

The recurring svnserve finding on engagements isn’t an exotic exploit — it’s anon-access = read. A team stands up svnserve to share code internally, leaves anonymous read on because “it’s only on the LAN,” and then the box ends up reachable from a segment it shouldn’t be. An attacker runs svn checkout svn://host/repo, walks away with the complete source tree, and then runs svn log -v to mine the history: old revisions still hold the database password that was “removed” two years ago, an AWS key in a committed .env, and the signing credentials for the deploy pipeline. No memory corruption, no brute force — just a plaintext protocol that hands over years of secrets to anyone who connects. Where the daemon is also an ancient build, the CVE-2004-0397 svnserve date-parsing exploit (still shipped in Metasploit) turns that same port into a pre-auth shell.

FAQ

What is port 3690 used for?

Port 3690/TCP is the default port for svnserve, the Apache Subversion daemon that serves repositories over the native svn:// protocol. Clients use it to check out, commit, and browse source code. Subversion can alternatively be served over HTTP(S) via mod_dav_svn on ports 80/443, or tunnelled over svn+ssh:// on port 22.

Is port 3690 dangerous?

It can be. Plain svn:// has no encryption, and many svnserve servers allow anonymous read, so an exposed port 3690 often lets anyone download the full source history — including secrets committed over the years. Old svnserve builds also carry pre-authentication remote-code-execution bugs. Treat an internet-facing 3690 as something to firewall and lock down.

What service runs on port 3690?

The svnserve daemon from Apache Subversion. It speaks the SVN wire protocol (svn://) and authenticates against a local passwd file using CRAM-MD5. It is distinct from the HTTP-based mod_dav_svn module, which serves the same repositories over ports 80 and 443.

How do I secure or close port 3690?

Firewall TCP/3690 to trusted hosts, set anon-access = none and require authentication, and move the transport to svn+ssh (port 22) or HTTPS. Rotate any secrets found in repository history, patch Subversion, and if the server is unmaintained, migrate the history to Git and stop svnserve. Rescan with nmap -p 3690 <target> to confirm it’s closed.

TL;DR

• Service: svnserve — Apache Subversion over the native svn:// protocol
• Default port: 3690/TCP (HTTP variant on 80/443, svn+ssh on 22)
• Biggest risk: anonymous read → full source and history disclosure, plus secrets buried in old revisions; plaintext auth and old-build RCE
• Mitigation: firewall 3690, disable anonymous access, encrypt via svn+ssh/HTTPS, rotate leaked secrets, patch or migrate off SVN