GeoServer security: keeping an exposed server up to date

Why an exposed GeoServer must stay up to date

GeoServer by nature answers requests from outside: its job is to serve maps and features to clients it does not know. Every WMS, WFS or WPS request is parsed by the server, and a flaw in that parsing can become a way in.

Like any software of this size, GeoServer regularly fixes vulnerabilities. The project ships maintenance releases and only patches branches that are still maintained. A server installed two years ago and never updated therefore piles up known, documented flaws, sometimes exploited by bots scanning the Internet.

Updating is not only about GeoServer. The server depends on a Java runtime, often a servlet container, extensions that must match exactly the same version, and the machine's operating system. A flaw in any of these layers exposes everything else. Keeping GeoServer up to date means keeping the whole stack beneath it up to date. Each of these components publishes its own fixes on its own schedule, so the watch has to cover all of them, not just the GeoServer release notes.

The CVE-2024-36401 case: remote code execution

On July 1, 2024, the GeoServer project published security advisory GHSA-6jj6-gm7p-fcvv. The GeoTools library evaluated property names as XPath expressions, which allowed arbitrary code execution on the server without authentication through ordinary WFS, WMS or WPS requests. Every default installation was affected.

Sources checked on 11/09/2026: advisory GHSA-6jj6-gm7p-fcvv on the GeoServer GitHub repository, and the CISA alert of July 15, 2024 on cisa.gov announcing the KEV addition.

This advisory shows how to read any GeoServer security bulletin. First, find the affected versions and compare them with yours. Then read the fixed versions: if your branch has none, the only way out is to move to another branch. The severity score sets the urgency: above 9, act the same day. The workaround section tells you what to do while waiting for the update, and what it will cost you in features. Finally, a listing in a catalog of exploited vulnerabilities means attacks are already happening: the question is no longer whether an exposed server will be targeted, but when. Keep a short record of each advisory you have assessed, with the decision taken and its date, so the next administrator knows what was already handled.

What this vulnerability teaches

• A public service is an attack surface. The flaw required no password: protecting the admin console was not enough.
• Timing matters. About a week passed between the advisory and the first observed exploitation. A quarterly update cycle does not protect against this kind of flaw.
• Old branches stay vulnerable. Only maintained branches received a fix; a very old installation had to change version, not just apply a patch.
• Know what is running. Many organizations discovered a forgotten GeoServer set up for a past project.

GeoServer security: best practices

• Change the default administrator password at installation, and create named accounts instead of sharing the admin account.
• Do not expose the admin console to the whole Internet: restrict it to an internal network, a VPN or an allow list of addresses.
• Stay on a maintained version and follow the project's security advisories on geoserver.org and its GitHub repository.
• Enable only the services you use. If WPS or WCS are unused, turn them off: fewer services, smaller surface.
• Set permissions per workspace and per layer, especially WFS-T write access.
• Put GeoServer behind an HTTPS reverse proxy, and log requests to spot unusual behavior.
• Use read-only database accounts for PostGIS stores that do not need to write.

The first point is not theoretical: GeoServer's documentation states that the console opens by default with the user admin and the password geoserver. These credentials are known to everyone, including bots that probe exposed servers. An online GeoServer that still accepts them should be treated as open.

Accounts, roles and access rules

GeoServer manages its own users, groups and roles, and applies two families of rules. Layer rules decide who can read, write or administer each workspace and layer. Service rules decide who can call a given operation, such as WFS writes. According to the project documentation, the default configuration lets any anonymous user read every layer and keeps writing for administrators: reasonable for public data, much less so for a workspace that mixes open and internal data.

# Layers: workspace.layer.mode=roles (r read, w write, a admin)
*.*.r=*
*.*.w=ROLE_ADMINISTRATOR
cadastre.*.r=ROLE_AGENTS

# Services: service.operation=roles
wfs.Transaction=ROLE_EDITORS

• One role per use, not per person: internal readers, editors, administrators. You then add or remove users without touching the rules.
• Separate data by workspace: one public workspace, one internal. Rules then take one line per workspace instead of one per layer.
• Restrict WFS-T writes to a specific role, even if the underlying PostGIS store already allows writes only on some tables: two locks are better than one.
• Do not mix both families for the same need: the documentation states that a service rule cannot target a specific layer. To protect a layer, you need a layer rule.
• Test with a non-admin account. An administrator sees everything; only a regular account, or an anonymous session, shows what the public actually gets.

Do not forget the REST API, which can configure everything programmatically: the documentation recommends locking it down with a catch-all rule that reserves all its methods for the administrator role. An automation script should then use a dedicated account, with a password distinct from those of people, stored in your secrets manager rather than in the script itself.

Configuring GeoServer for production

An out-of-the-box installation is set up for exploring the software, not for exposure. The GeoServer documentation devotes a whole part to running in production; here are the settings that directly affect security.

• Logging: choose the production profile, which is leaner, and keep logs long enough to trace back an incident.
• Verbose exceptions: the option that adds the Java stack trace to error messages is meant for debugging; the documentation recommends it for testing only. In production it needlessly tells an attacker about the server's internals.
• Global services: when disabled, clients must go through each workspace's own services, which isolates data better.
• Unused services: a service can be turned off from the console, or through a system property listing several at once. A WPS or WCS that nobody calls should not answer.
• Admin console: when administration goes through the REST API or deployed files, the web console can be disabled entirely with a Java property at startup. Otherwise it stays reachable but filtered by the reverse proxy.

Record every setting in an operations document, with its reason. At the next update or the next change of administrator, that document is what prevents an accidental return to a demo configuration.

A realistic update routine

1. Subscribe to GeoServer security announcements and note the latest maintained branch.
2. Back up the data directory (configuration, styles, layers) before any update.
3. Test the new version on a copy: layers, SLD styles, installed extensions.
4. Apply in production, then check GetCapabilities and a few key layers in QGIS.
5. For a critical flaw, do not wait for the usual window: apply the published fix or workaround the same day.

This routine takes time, especially when extensions must follow the same version. It is one of the hidden costs of self-hosting covered in our guide on the cost of an open source web GIS. Taken together, the lessons of CVE-2024-36401 point to one conclusion: security is not a setting applied once at installation, but an ongoing routine with a named owner, a list of servers and a way to act within days, not months.

To keep the testing step within a day, prepare a fixed checklist: read the GetCapabilities of each service, display three or four representative layers as WMS, run a WFS request on a large table, perform a WFS-T edit if you offer editing, log in with a non-admin account, then read the logs for startup errors. Also check that every extension loaded and that the tile cache still serves your cached layers. If everything passes on the copy, going to production is no longer a leap into the unknown, and the same checklist serves again after the production update.

Inventory, monitor and respond

GeoServer security starts with a simple question: how many GeoServers does your organization run, and on which versions? Many teams discover, during an alert, a test server left online or an installation set up by a contractor and then forgotten. An up-to-date list is worth more than the best configuration applied to half of your servers.

• List every GeoServer: URL, version, branch, installed extensions, owner, date of the last update.
• Check external exposure: from a third-party network, the admin console should not answer, while public services do.
• Watch the logs: bursts of requests, unusual parameters in filters or WPS calls nobody uses are warning signs.
• Prepare a response plan: who decides to stop a service, how to cut it off quickly, where the latest data directory backup is.
• Apply published workarounds when the update cannot wait. For CVE-2024-36401, the project advisory suggested removing a GeoTools component (gt-complex) until the update, at the cost of some advanced features, or dropping in patched files for older versions.

A workaround is temporary: it reduces risk while you schedule the real update, it does not replace it. Finally, if you suspect a compromise, an update alone is not enough: check that nothing was planted on the server in the meantime, and if needed start again from a clean installation with a restored data directory.

The most common security mistakes

Most of these mistakes come not from a lack of skill but from a lack of time: a server set up for a project, then left aside once the project shipped. That is why GeoServer security is mostly about organization: a named owner, an up-to-date list and a routine that is actually followed, more than any single setting.

Delegate security without giving up GeoServer

With GeoServer Cloud, GeoServer is installed, secured, updated and monitored by LizPack. You work in an isolated workspace with the usual GeoServer console, without managing Java or a server. Other accounts' layers are neither visible nor accessible.

If your data must stay on your premises, LizPack Enterprise installs GeoServer on your infrastructure, managed from a portal. To compare hosting options, see online GeoServer hosting, and to place GeoServer among other servers, our comparison. Delegating does not remove your own responsibilities: you still choose strong passwords for your accounts, decide which layers are public, and review who has access to your workspace.

Frequently asked questions