Safeguard
Vulnerability Analysis•

CVE-2024-56511: Critical Authentication Bypass in DataEase

CVE-2024-56511 lets requests skip DataEase authentication when a custom context path is set. Upgrade to 2.10.4 and review your context path setting.

Safeguard Security Team
3 min read

CVE-2024-56511 is a critical severity authentication bypass (CVSS 9.8) in DataEase, an open source data visualization tool. Versions up to 2.10.3 can be tricked into skipping the token check when a custom context path is configured. Upgrade to 2.10.4, the fixed release.

What's affected

The GitHub advisory GHSA-9f69-p73j-m73x lists the Maven package io.dataease with affected versions up to and including 2.10.3 and the patched version 2.10.4.

The advisory also describes the condition. The flaw matters when whoever deployed the product has set server.servlet.context-path, the setting that serves the application under a path prefix instead of the root. Deployments served from the root path are described differently, so check your configuration. The advisory names no workaround beyond upgrading.

How to check if you're exposed

Check the version in the DataEase interface, or from the container image tag, and compare it to 2.10.4.

Then look at your application configuration for the context path setting:

grep -rn "context-path" application.yml

If the value is set, you match the condition in the advisory. If you cannot find the file, look at the environment variables passed to the container, because Spring Boot applications accept the same property as SERVER_SERVLET_CONTEXT_PATH.

Also look at network exposure. A DataEase server that is reachable from the internet is a much bigger concern than one only reachable from an internal network, because the vector in the record shows no privileges and no user interaction.

What to do now

  1. Identify all DataEase deployments and their versions.
  2. Upgrade to 2.10.4 or later.
  3. Check whether a custom context path is configured, and note it in the change record.
  4. Put the service behind a reverse proxy or VPN so it is not directly reachable from the internet.
  5. Review data sources connected to DataEase, since a dashboard tool often holds database credentials. Rotate any that may have been exposed.
  6. Check access logs for unauthenticated requests that returned normal data from before the upgrade.

Why it matters

The record maps this to CWE-289, authentication bypass by alternate name. The advisory explains the mechanism at a high level. The filter that checks for a token decides whether a URL is on a list of paths that need no login. It reads the raw request path and compares it with that list. The comparison removed semicolons, a known trick, but it did not account for path segments that move up a directory. When the application is served under a context path, a request can begin with a whitelisted prefix and still end up at a protected interface.

This is a classic case of two parts of a system reading the same URL differently. The security filter sees one path, the router resolves another. Allow lists based on prefix matching need to run on a normalized path. The KEV flag in the record is false, but the advisory is public and the condition is easy to check, so patch quickly.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Is my DataEase safe if I serve it at the root path?

The advisory ties the bypass to deployments that set a context path. Upgrade anyway, since configuration can change.

What is the fixed version of DataEase for CVE-2024-56511?

Version 2.10.4, per the project's GitHub advisory.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.