GHSA-M8P8-53VF-8357

Vulnerability from github – Published: 2026-03-30 16:33 – Updated: 2026-03-30 21:25
VLAI?
Summary
Nginx Configuration Directory Vulnerable to Recursive Deletion via Improper Path Validation
Details

Summary

The nginx-ui configuration improperly handles URL-encoded traversal sequences. When specially crafted paths are supplied, the backend resolves them to the base Nginx configuration directory and executes the operation on the base directory (/etc/nginx). In particular, this allows an authenticated user to remove the entire /etc/nginx directory, resulting in a partial Denial of Service.

Details

The file deletion logic fails to correctly validate and normalize paths containing URL-encoded traversal sequences such as ..%252F.

When such input is processed, the internal path resolution logic attempts to clamp the path into the allowed configuration directory. Instead of rejecting the traversal attempt, the clamping mechanism resolves the path to the base Nginx configuration directory itself.

Because the deletion handler invokes os.RemoveAll, which recursively removes directories, this results in the deletion of the entire /etc/nginx directory.

This behavior creates a dangerous interaction between path normalization and deletion logic:

  • Traversal sequences are not rejected.
  • Double-encoding (..%252F) is used to bypass initial shallow filters.
  • The clamping mechanism resolves malicious paths to the base configuration directory.
  • The deletion handler recursively deletes the resolved path.

As a result, an attacker can trigger deletion of the entire Nginx configuration directory instead of being blocked by path validation logic.

Root Cause

The vulnerability results from a combination of design flaws:

  • Improper Path Canonicalization: URL-encoded traversal sequences are not properly rejected.
  • Unsafe Fallback Logic: The GetConfPath clamping mechanism returns the base configuration directory when traversal is detected instead of rejecting the request.
  • Unsafe Deletion Primitive: The deletion handler invokes os.RemoveAll, which recursively deletes directories without additional safeguards. (delete.go)
    // Delete the file or directory
    err = os.RemoveAll(fullPath)
    if err != nil {
        cosy.ErrHandler(c, err)
        return
    }

This interaction causes the deletion operation to target the most sensitive directory when a traversal attempt occurs.

Environment

  • Server OS: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64)
  • Nginx UI Version: nginx-ui v2.3.3
  • Deployment: Docker / Default installation

Proof of Concept

Steps to Reproduce

  1. Log into nginx-ui.

  2. Go to Manage Configs and create a Folder named ..%252F..%252F..%252F..%252Ftest image

  3. Observe that the backend resolves the path to /etc/nginx..

  4. Now lets create a file called testing.

  5. Save it and rename it to ..%252F..%252F..%252F..%252Ftest (It is not possible to create it directly with the payload name so we have to rename it)

  6. Go back to manage configs and Click Delete to remove the file we just created.

  7. Check that there is an error: image

  8. Reload the website and check that the /etc/nginx folder has been completely removed: image

Impact

An authenticated user capable of invoking the configuration deletion endpoint can trigger the recursive deletion of the entire Nginx configuration directory (/etc/nginx).

This results in: - Immediate failure of the Nginx service due to missing configuration files. - Loss of all Nginx configuration managed by nginx-ui. - Denial of Service for all web services relying on the affected Nginx instance.

As the deletion operation uses a recursive filesystem call, the entire configuration directory is removed, leaving the system unable to restart Nginx until the configuration is manually restored.

A patched version is available at https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/0xJacky/Nginx-UI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.99"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33027"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-30T16:33:00Z",
    "nvd_published_at": "2026-03-30T18:16:18Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nThe nginx-ui configuration improperly handles URL-encoded traversal sequences. When specially crafted paths are supplied, the backend resolves them to the base Nginx configuration directory and executes the operation on the base directory (/etc/nginx). In particular, this allows an authenticated user to remove the entire `/etc/nginx` directory, resulting in a partial Denial of Service.\n\n## Details\nThe file deletion logic fails to correctly validate and normalize paths containing URL-encoded traversal sequences such as `..%252F`.\n\nWhen such input is processed, the internal path resolution logic attempts to clamp the path into the allowed configuration directory. Instead of rejecting the traversal attempt, the clamping mechanism resolves the path to the base Nginx configuration directory itself.\n\nBecause the deletion handler invokes `os.RemoveAll`, which recursively removes directories, this results in the deletion of the entire `/etc/nginx` directory.\n\nThis behavior creates a dangerous interaction between path normalization and deletion logic:\n\n- Traversal sequences are not rejected.\n- Double-encoding (`..%252F`) is used to bypass initial shallow filters.\n- The clamping mechanism resolves malicious paths to the base configuration directory.\n- The deletion handler recursively deletes the resolved path.\n\nAs a result, an attacker can trigger deletion of the entire Nginx configuration directory instead of being blocked by path validation logic.\n\n### Root Cause\n\nThe vulnerability results from a combination of design flaws:\n\n- **Improper Path Canonicalization**: URL-encoded traversal sequences are not properly rejected.\n- **Unsafe Fallback Logic**: The `GetConfPath` clamping mechanism returns the base configuration directory when traversal is detected instead of rejecting the request.\n- **Unsafe Deletion Primitive**: The deletion handler invokes `os.RemoveAll`, which recursively deletes directories without additional safeguards. (delete.go)\n```\n\t// Delete the file or directory\n\terr = os.RemoveAll(fullPath)\n\tif err != nil {\n\t\tcosy.ErrHandler(c, err)\n\t\treturn\n\t}\n```\nThis interaction causes the deletion operation to target the most sensitive directory when a traversal attempt occurs.\n\n### Environment\n- **Server OS**: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64)\n- **Nginx UI Version**:  nginx-ui v2.3.3\n- **Deployment**: Docker / Default installation\n\n\n## Proof of Concept\n### Steps to Reproduce\n1. Log into nginx-ui.\n\n2. Go to Manage Configs and create a Folder named *..%252F..%252F..%252F..%252Ftest*\n\u003cimg width=\"1608\" height=\"559\" alt=\"image\" src=\"https://github.com/user-attachments/assets/738d7d65-7e13-48fa-affc-d5509c43900f\" /\u003e\n\n3. Observe that the backend resolves the path to /etc/nginx.. \n\n4. Now lets create a file called *testing*. \n\n5. Save it and rename it to *..%252F..%252F..%252F..%252Ftest* (It is not possible to create it directly with the payload name so we have to rename it)\n\n6. Go back to manage configs and Click Delete to remove the file we just created. \n\n7. Check that there is an error: \n\u003cimg width=\"1578\" height=\"696\" alt=\"image\" src=\"https://github.com/user-attachments/assets/51a36310-0676-4fe5-b80c-e0199498efbf\" /\u003e\n\n8. Reload the website and check that the /etc/nginx folder has been completely removed: \n\u003cimg width=\"1313\" height=\"722\" alt=\"image\" src=\"https://github.com/user-attachments/assets/0a9ddd1b-786b-4cf2-8abd-1dc6f3a77807\" /\u003e\n\n\n## Impact\n\nAn authenticated user capable of invoking the configuration deletion endpoint can trigger the recursive deletion of the entire Nginx configuration directory (`/etc/nginx`).\n\nThis results in:\n- Immediate failure of the Nginx service due to missing configuration files.\n- Loss of all Nginx configuration managed by nginx-ui.\n- Denial of Service for all web services relying on the affected Nginx instance.\n\nAs the deletion operation uses a recursive filesystem call, the entire configuration directory is removed, leaving the system unable to restart Nginx until the configuration is manually restored.\n\nA patched version is available at https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4.",
  "id": "GHSA-m8p8-53vf-8357",
  "modified": "2026-03-30T21:25:41Z",
  "published": "2026-03-30T16:33:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-m8p8-53vf-8357"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33027"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/0xJacky/nginx-ui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Nginx Configuration Directory Vulnerable to Recursive Deletion via Improper Path Validation"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…