CWE-226
AllowedSensitive Information in Resource Not Removed Before Reuse
Abstraction: Base · Status: Draft
The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.
67 vulnerabilities reference this CWE, most recent first.
GHSA-R7P8-XQ5M-436C
Vulnerability from github – Published: 2026-04-14 00:06 – Updated: 2026-04-14 00:06Description (as reported)
A security vulnerability has been identified in Jetty's JaspiAuthenticator.java.
The root cause is a failure to consistently clear authentication metadata stored in ThreadLocal during certain error or incomplete authentication flows.
Specifically, after a GroupPrincipalCallback is persisted into the ThreadLocal, the authentication process may exit prematurely — before the ThreadLocal storage is cleared — if a mandatory CallerPrincipalCallback is missing or an exception occurs.
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.
See also attached PDF.
Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).
Patches
No patches yet.
Workarounds
Do not use Jetty's JASPI.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee11:jetty-ee11-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee10:jetty-ee10-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee9:jetty-ee9-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee8:jetty-ee8-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.33"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee11:jetty-ee11-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.33"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee10:jetty-ee10-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.33"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee9:jetty-ee9-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.33"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee8:jetty-ee8-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.28"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.0.29"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.28"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.29"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.4.60"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-jaspi"
},
"ranges": [
{
"events": [
{
"introduced": "9.4.0"
},
{
"fixed": "9.4.61"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-5795"
],
"database_specific": {
"cwe_ids": [
"CWE-226",
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T00:06:27Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Description (as reported)\n\nA security vulnerability has been identified in Jetty\u0027s `JaspiAuthenticator.java`. \n\nThe root cause is a failure to consistently clear authentication metadata stored in `ThreadLocal` during certain error or incomplete authentication flows. \nSpecifically, after a `GroupPrincipalCallback` is persisted into the `ThreadLocal`, the authentication process may exit prematurely \u2014 before the `ThreadLocal` storage is cleared \u2014 if a mandatory `CallerPrincipalCallback` is missing or an exception occurs. \nThis allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.\n\nSee also attached PDF.\n\n### Impact\nAn unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).\n\n### Patches\nNo patches yet.\n\n### Workarounds\nDo not use Jetty\u0027s JASPI.",
"id": "GHSA-r7p8-xq5m-436c",
"modified": "2026-04-14T00:06:27Z",
"published": "2026-04-14T00:06:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-r7p8-xq5m-436c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5795"
},
{
"type": "PACKAGE",
"url": "https://github.com/jetty/jetty.project"
},
{
"type": "WEB",
"url": "https://github.com/user-attachments/files/26118760/JaspiAuthenticator_Security_Report.pdf"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/issues/92"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables"
}
GHSA-RHWX-656Q-5R7X
Vulnerability from github – Published: 2024-11-13 21:30 – Updated: 2024-11-13 21:30Sensitive information in resource not removed before reuse in some Intel(R) TDX Seamldr module software before version 1.5.02.00 may allow a privileged user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2024-21850"
],
"database_specific": {
"cwe_ids": [
"CWE-226"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-13T21:15:09Z",
"severity": "HIGH"
},
"details": "Sensitive information in resource not removed before reuse in some Intel(R) TDX Seamldr module software before version 1.5.02.00 may allow a privileged user to potentially enable escalation of privilege via local access.",
"id": "GHSA-rhwx-656q-5r7x",
"modified": "2024-11-13T21:30:35Z",
"published": "2024-11-13T21:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21850"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01076.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-VWJ9-2733-P4WV
Vulnerability from github – Published: 2024-10-31 18:31 – Updated: 2024-10-31 18:31When using Arm Cortex-M Security Extensions (CMSE), Secure stack contents can be leaked to Non-secure state via floating-point registers when a Secure to Non-secure function call is made that returns a floating-point value and when this is the first use of floating-point since entering Secure state. This allows an attacker to read a limited quantity of Secure stack contents with an impact on confidentiality. This issue is specific to code generated using LLVM-based compilers.
{
"affected": [],
"aliases": [
"CVE-2024-7883"
],
"database_specific": {
"cwe_ids": [
"CWE-226"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-31T17:15:14Z",
"severity": "LOW"
},
"details": "When using Arm Cortex-M Security Extensions (CMSE), Secure stack \ncontents can be leaked to Non-secure state via floating-point registers \nwhen a Secure to Non-secure function call is made that returns a \nfloating-point value and when this is the first use of floating-point \nsince entering Secure state. This allows an attacker to read a limited \nquantity of Secure stack contents with an impact on confidentiality. \nThis issue is specific to code generated using LLVM-based compilers.",
"id": "GHSA-vwj9-2733-p4wv",
"modified": "2024-10-31T18:31:19Z",
"published": "2024-10-31T18:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7883"
},
{
"type": "WEB",
"url": "https://developer.arm.com/Arm%20Security%20Center/Cortex-M%20Security%20Extensions%20Vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WH6W-3828-G9QF
Vulnerability from github – Published: 2022-11-10 21:16 – Updated: 2025-05-02 12:51Impact
There is a bug in Wasmtime's implementation of it's pooling instance allocator where when a linear memory is reused for another instance the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. The pooling instance allocator in Wasmtime works by preallocating virtual memory for a fixed number of instances to reside in and then new instantiations pick a slot to use. Most conventional modules additionally have an initial copy-on-write "heap image" which is mapped in Wasmtime into the linear memory slot. When a heap slot is deallocated Wasmtime resets all of its contents back to the initial state but it does not unmap the image in case the next instance is an instantiation of the same module.
The bug in Wasmtime occurs when a slot in the pooling allocator previously was used for a module with a heap image, meaning that its current state of memory contains the initial heap contents of that module. If the next instantiation within that slot does not itself contain a heap image then Wasmtime would leave the old heap image in place erroneously and continue with instantiation. This means that instantiations of modules without a heap image can see the initial heap image of the prior instantiation within that slot.
Heap images in Wasmtime are created by precomputing WebAssembly data segments into one large mapping to be placed into linear memory at a particular offset. Most modules produced by toolchains today will have a heap image and an initialization snapshot. Creating a module without a heap image would require a hand-crafted *.wat file or a specially crafted source program. This consequence means that this bug is highly unlikely to be accidentally triggered and would otherwise require an intentional trigger with a hand-crafted module.
One important part of this vulnerability is Wasmtime is highly likely to segfault when the slot is reused again with a module that itself has an initialization image. For example if module A has a heap initialization image and module B does not have a heap initialization image, then the following sequence of events could happen if they all are instantiated into the same instance slot:
- Module A is instantiated, and then deallocated. This leaves A's heap image in place, reset to its initial contents.
- Module B is instantiated and erroneously can see the initial heap contents of A. Module B is then deallocated and the entire heap is unmapped and reset back to zero.
- Module A is instantiated again, but the state tracking the slot did not account for module B so it thinks the module image is still mapped and proceeds with instantiation. Any action on A's part to access linear memory will then trap and if the host accesses A's memory it will segfault because the data that's supposed to be mapped is all unmapped.
Adding this all together this means that in practice modules must be deliberately crafted to not have an initial heap image to view the contents of a prior image. If this module is instantiated though then when the slot is reused the next, likely image-using, module will believe its memory is mapped when it isn't, causing the host to segfault on unmapped memory it believed was mapped.
Patches
This bug has been patched and users should upgrade to Wasmtime 2.0.2.
Workarounds
Trigging this bug requires the pooling allocator to be configured and for copy-on-write heap images to also be enabled. Pooling allocation is not enabled by default but copy-on-write heap images are. Mitigations for this bug include:
- Disabling the pooling allocator - note that pooling allocation is not enabled by default in Wasmtime
- Disabling the
memory-init-cowfeature or withConfig::memory_init_cow
References
Config::allocation_strategy- configuration required to enable the pooling allocator.Config::memory_init_cow- configuration required to enable or disable copy-on-write (this is enabled by default).- Mailing list announcement
- Patch for
release-2.0.0branch - Patch for
main
For more information
If you have any questions or comments about this advisory:
- Reach out to us on the Bytecode Alliance Zulip chat
- Open an issue in the bytecodealliance/wasmtime repository
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39393"
],
"database_specific": {
"cwe_ids": [
"CWE-212",
"CWE-226"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-10T21:16:22Z",
"nvd_published_at": "2022-11-10T20:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nThere is a bug in Wasmtime\u0027s implementation of it\u0027s pooling instance allocator where when a linear memory is reused for another instance the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. The pooling instance allocator in Wasmtime works by preallocating virtual memory for a fixed number of instances to reside in and then new instantiations pick a slot to use. Most conventional modules additionally have an initial copy-on-write \"heap image\" which is mapped in Wasmtime into the linear memory slot. When a heap slot is deallocated Wasmtime resets all of its contents back to the initial state but it does not unmap the image in case the next instance is an instantiation of the same module.\n\nThe bug in Wasmtime occurs when a slot in the pooling allocator previously was used for a module with a heap image, meaning that its current state of memory contains the initial heap contents of that module. If the next instantiation within that slot does not itself contain a heap image then Wasmtime would leave the old heap image in place erroneously and continue with instantiation. This means that instantiations of modules without a heap image can see the initial heap image of the prior instantiation within that slot.\n\nHeap images in Wasmtime are created by precomputing WebAssembly `data` segments into one large mapping to be placed into linear memory at a particular offset. Most modules produced by toolchains today will have a heap image and an initialization snapshot. Creating a module without a heap image would require a hand-crafted `*.wat` file or a specially crafted source program. This consequence means that this bug is highly unlikely to be accidentally triggered and would otherwise require an intentional trigger with a hand-crafted module.\n\nOne important part of this vulnerability is Wasmtime is highly likely to segfault when the slot is reused again with a module that itself has an initialization image. For example if module A has a heap initialization image and module B does not have a heap initialization image, then the following sequence of events could happen if they all are instantiated into the same instance slot:\n\n* Module A is instantiated, and then deallocated. This leaves A\u0027s heap image in place, reset to its initial contents.\n* Module B is instantiated and erroneously can see the initial heap contents of A. Module B is then deallocated and the entire heap is unmapped and reset back to zero.\n* Module A is instantiated again, but the state tracking the slot did not account for module B so it thinks the module image is still mapped and proceeds with instantiation. Any action on A\u0027s part to access linear memory will then trap and if the host accesses A\u0027s memory it will segfault because the data that\u0027s supposed to be mapped is all unmapped.\n\nAdding this all together this means that in practice modules must be deliberately crafted to not have an initial heap image to view the contents of a prior image. If this module is instantiated though then when the slot is reused the next, likely image-using, module will believe its memory is mapped when it isn\u0027t, causing the host to segfault on unmapped memory it believed was mapped. \n\n### Patches\n\nThis bug has been patched and users should upgrade to Wasmtime 2.0.2.\n\n### Workarounds\n\nTrigging this bug requires the pooling allocator to be configured and for copy-on-write heap images to also be enabled. Pooling allocation is not enabled by default but copy-on-write heap images are. Mitigations for this bug include:\n\n* Disabling the pooling allocator - note that pooling allocation is not enabled by default in Wasmtime\n* Disabling the `memory-init-cow` feature or with [`Config::memory_init_cow`](https://docs.rs/wasmtime/2.0.1/wasmtime/struct.Config.html#method.memory_init_cow)\n\n### References\n\n* [`Config::allocation_strategy`](https://docs.rs/wasmtime/2.0.1/wasmtime/struct.Config.html#method.allocation_strategy) - configuration required to enable the pooling allocator.\n* [`Config::memory_init_cow`](https://docs.rs/wasmtime/2.0.1/wasmtime/struct.Config.html#method.memory_init_cow) - configuration required to enable or disable copy-on-write (this is enabled by default).\n* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/c1HBDDJwNPA)\n* [Patch for `release-2.0.0` branch](https://github.com/bytecodealliance/wasmtime/commit/2614f2e9d2d36805ead8a8da0fa0c6e0d9e428a0)\n* [Patch for `main`](https://github.com/bytecodealliance/wasmtime/commit/3535acbf3be032ef1ba0b469b8ab92538a8a18a6)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)\n* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)",
"id": "GHSA-wh6w-3828-g9qf",
"modified": "2025-05-02T12:51:03Z",
"published": "2022-11-10T21:16:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-wh6w-3828-g9qf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39393"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/commit/2614f2e9d2d36805ead8a8da0fa0c6e0d9e428a0"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/commit/3535acbf3be032ef1ba0b469b8ab92538a8a18a6"
},
{
"type": "PACKAGE",
"url": "https://github.com/bytecodealliance/wasmtime"
},
{
"type": "WEB",
"url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/c1HBDDJwNPA"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2022-0075.html"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2022-0098.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Wasmtime may have data leakage between instances in the pooling allocator"
}
GHSA-X43Q-54P7-VW63
Vulnerability from github – Published: 2023-11-09 15:30 – Updated: 2023-11-09 15:30The AppsAnywhere macOS client-privileged helper can be tricked into executing arbitrary commands with elevated permissions by a local user process.
{
"affected": [],
"aliases": [
"CVE-2023-41138"
],
"database_specific": {
"cwe_ids": [
"CWE-226",
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-09T15:15:08Z",
"severity": "HIGH"
},
"details": "The AppsAnywhere macOS client-privileged helper can be tricked into executing arbitrary commands with elevated permissions by a local user process.",
"id": "GHSA-x43q-54p7-vw63",
"modified": "2023-11-09T15:30:30Z",
"published": "2023-11-09T15:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41138"
},
{
"type": "WEB",
"url": "https://docs.appsanywhere.com/appsanywhere/3.1/2023-11-security-advisory"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X6M9-38VM-2XHF
Vulnerability from github – Published: 2026-03-24 22:09 – Updated: 2026-07-06 13:07Summary
TemplateContext.Reset() claims that a TemplateContext can be reused safely on the same thread, but it does not clear CachedTemplates. If an application pools TemplateContext objects and uses an ITemplateLoader that resolves content per request, tenant, or user, a previously authorized include can be served to later renders without calling TemplateLoader.Load() again.
Details
The relevant code path is:
TemplateContext.Reset()only clears output, globals, cultures, and source files insrc/Scriban/TemplateContext.cslines 877–902.CachedTemplatesis initialized once and kept on the context insrc/Scriban/TemplateContext.csline 197.includeresolves templates throughIncludeFunction.Invoke()insrc/Scriban/Functions/IncludeFunction.cslines 29–43.IncludeFunction.Invoke()callsTemplateContext.GetOrCreateTemplate()insrc/Scriban/TemplateContext.cslines 1249–1256.- If a template path is already present in
CachedTemplates, Scriban returns the cached compiled template and does not callTemplateLoader.Load()again.
This becomes a security issue when ITemplateLoader.Load() returns request-dependent content. A first render can prime the cache with an admin-only or tenant-specific template, and later renders on the same reused TemplateContext will receive that stale template even after Reset().
Proof of Concept
Setup
mkdir scriban-poc1
cd scriban-poc1
dotnet new console --framework net8.0
dotnet add package Scriban --version 6.6.0
Program.cs
using Scriban;
using Scriban.Parsing;
using Scriban.Runtime;
var loader = new SwitchingLoader();
var context = new TemplateContext
{
TemplateLoader = loader,
};
var template = Template.Parse("{{ include 'profile' }}");
loader.Content = "admin-only";
Console.WriteLine("first=" + template.Render(context));
context.Reset();
loader.Content = "guest-view";
Console.WriteLine("second=" + template.Render(context));
sealed class SwitchingLoader : ITemplateLoader
{
public string Content { get; set; } = string.Empty;
public string GetPath(TemplateContext context, SourceSpan callerSpan, string templateName) => templateName;
public string Load(TemplateContext context, SourceSpan callerSpan, string templatePath) => Content;
public ValueTask<string> LoadAsync(TemplateContext context, SourceSpan callerSpan, string templatePath)
=> new(Content);
}
Run
dotnet run
Actual Output
first=admin-only
second=admin-only
Expected Output
first=admin-only
second=guest-view
The second render should reload the template after Reset(), but it instead reuses the cached compiled template from the previous render.
Impact
This is a cross-render data isolation issue. Any application that reuses TemplateContext objects and uses a request-dependent ITemplateLoader can leak previously authorized template content across requests, users, or tenants.
The issue impacts applications that:
- Pool or reuse
TemplateContext - Call
Reset()between requests - Use
include - Resolve include content based on request-specific state
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "scriban"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Scriban.Signed"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-226"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T22:09:49Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\n`TemplateContext.Reset()` claims that a `TemplateContext` can be reused safely on the same thread, but it does not clear `CachedTemplates`. If an application pools `TemplateContext` objects and uses an `ITemplateLoader` that resolves content per request, tenant, or user, a previously authorized include can be served to later renders without calling `TemplateLoader.Load()` again.\n\n## Details\n\nThe relevant code path is:\n\n- `TemplateContext.Reset()` only clears output, globals, cultures, and source files in `src/Scriban/TemplateContext.cs` lines 877\u2013902.\n- `CachedTemplates` is initialized once and kept on the context in `src/Scriban/TemplateContext.cs` line 197.\n- `include` resolves templates through `IncludeFunction.Invoke()` in `src/Scriban/Functions/IncludeFunction.cs` lines 29\u201343.\n- `IncludeFunction.Invoke()` calls `TemplateContext.GetOrCreateTemplate()` in `src/Scriban/TemplateContext.cs` lines 1249\u20131256.\n- If a template path is already present in `CachedTemplates`, Scriban returns the cached compiled template and does **not** call `TemplateLoader.Load()` again.\n\nThis becomes a security issue when `ITemplateLoader.Load()` returns request-dependent content. A first render can prime the cache with an admin-only or tenant-specific template, and later renders on the same reused `TemplateContext` will receive that stale template even after `Reset()`.\n\n---\n\n## Proof of Concept\n\n### Setup\n\n```bash\nmkdir scriban-poc1\ncd scriban-poc1\ndotnet new console --framework net8.0\ndotnet add package Scriban --version 6.6.0\n```\n\n### `Program.cs`\n\n```csharp\nusing Scriban;\nusing Scriban.Parsing;\nusing Scriban.Runtime;\n\nvar loader = new SwitchingLoader();\nvar context = new TemplateContext\n{\n TemplateLoader = loader,\n};\n\nvar template = Template.Parse(\"{{ include \u0027profile\u0027 }}\");\n\nloader.Content = \"admin-only\";\nConsole.WriteLine(\"first=\" + template.Render(context));\n\ncontext.Reset();\n\nloader.Content = \"guest-view\";\nConsole.WriteLine(\"second=\" + template.Render(context));\n\nsealed class SwitchingLoader : ITemplateLoader\n{\n public string Content { get; set; } = string.Empty;\n\n public string GetPath(TemplateContext context, SourceSpan callerSpan, string templateName) =\u003e templateName;\n\n public string Load(TemplateContext context, SourceSpan callerSpan, string templatePath) =\u003e Content;\n\n public ValueTask\u003cstring\u003e LoadAsync(TemplateContext context, SourceSpan callerSpan, string templatePath)\n =\u003e new(Content);\n}\n```\n\n### Run\n\n```bash\ndotnet run\n```\n\n### Actual Output\n\n```\nfirst=admin-only\nsecond=admin-only\n```\n\n### Expected Output\n\n```\nfirst=admin-only\nsecond=guest-view\n```\n\nThe second render should reload the template after `Reset()`, but it instead reuses the cached compiled template from the previous render.\n\n---\n\n## Impact\n\nThis is a cross-render data isolation issue. Any application that reuses `TemplateContext` objects and uses a request-dependent `ITemplateLoader` can leak previously authorized template content across requests, users, or tenants.\n\nThe issue impacts applications that:\n\n- Pool or reuse `TemplateContext`\n- Call `Reset()` between requests\n- Use `include`\n- Resolve include content based on request-specific state",
"id": "GHSA-x6m9-38vm-2xhf",
"modified": "2026-07-06T13:07:43Z",
"published": "2026-03-24T22:09:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/scriban/scriban/security/advisories/GHSA-x6m9-38vm-2xhf"
},
{
"type": "PACKAGE",
"url": "https://github.com/scriban/scriban"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Scriban has an authorization bypass due to stale include cache surviving TemplateContext.Reset() "
}
GHSA-XXHX-7292-7RV8
Vulnerability from github – Published: 2026-01-14 12:31 – Updated: 2026-01-20 18:31In certain Arm CPUs, a CPP RCTX instruction executed on one Processing Element (PE) may inhibit TLB invalidation when a TLBI is issued to the PE, either by the same PE or another PE in the shareability domain. In this case, the PE may retain stale TLB entries which should have been invalidated by the TLBI.
{
"affected": [],
"aliases": [
"CVE-2025-0647"
],
"database_specific": {
"cwe_ids": [
"CWE-226"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-14T11:15:50Z",
"severity": "MODERATE"
},
"details": "In certain Arm CPUs, a CPP RCTX instruction executed on one Processing Element (PE) may inhibit TLB invalidation when a TLBI is issued to the PE, either by the same PE or another PE in the shareability domain. In this case, the PE may retain stale TLB entries which should have been invalidated by the TLBI.",
"id": "GHSA-xxhx-7292-7rv8",
"modified": "2026-01-20T18:31:55Z",
"published": "2026-01-14T12:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0647"
},
{
"type": "WEB",
"url": "https://developer.arm.com/documentation/111546"
},
{
"type": "WEB",
"url": "https://graph.volerion.com/view?ID=CVE-2025-0647"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
During critical state transitions, information not needed in the next state should be removed or overwritten with fixed patterns (such as all 0's) or random data, before the transition to the next state.
Mitigation
When releasing, de-allocating, or deleting a resource, overwrite its data and relevant metadata with fixed patterns or random data. Be cautious about complex resource types whose underlying representation might be non-contiguous or change at a low level, such as how a file might be split into different chunks on a file system, even though "logical" file positions are contiguous at the application layer. Such resource types might require invocation of special modes or APIs to tell the underlying operating system to perform the necessary clearing, such as SDelete (Secure Delete) on Windows, although the appropriate functionality might not be available at the application layer.
CAPEC-37: Retrieve Embedded Sensitive Data
An attacker examines a target system to find sensitive data that has been embedded within it. This information can reveal confidential contents, such as account numbers or individual keys/credentials that can be used as an intermediate step in a larger attack.