Two widely-deployed open-source components now have complete, end-to-end Metasploit exploits. Apache ActiveMQ's broker deserialization path and Gogs' git rebase handler each accept externally-originating data and pass it unsanitized to a dangerous sink — a classic taint-flow pattern. If your static analysis tool cannot trace data from source to sink across serialization boundaries and process forks, you are finding these vulnerabilities only after the exploit kit ships. That is the wrong side of the timeline.
ActiveMQ: Deserialization as a Tainted-Data Highway
ActiveMQ's OpenWire protocol transports serialized Java objects directly into the broker's classpath. When a client sends an ExceptionResponse or a crafted MessageDispatch, the broker calls ObjectInputStream.readObject on the raw wire payload — no allow-list, no type filtering. The malicious object's readResolve chain executes arbitrary OS commands under the broker process. Security Reviewer's forward taint analysis traces the byte stream from the TCP transport entry point through protocol decoding into the readObject call, flags the sink as a deserialization gadget entry, and reports the vulnerable path with the exact source file and line. The remediation guidance names the replacement pattern — ObjectInputFilter or allow-listed deserialization — and maps it to the same location, so the developer does not have to rediscover the data flow manually.
Gogs: Unsanitized Rebase Input to Command Execution
Gogs exposes a repository rebase endpoint that accepts user-controlled branch and remote references. Internally the handler assembles a git rebase command string by interpolating these inputs without quoting or validation, then passes it to an exec call. An attacker who controls the repository name or branch string injects shell metacharacters that the OS executes as a subcommand. Security Reviewer's taint engine follows the HTTP parameter from the route handler through string concatenation into the exec.Command sink, marks the concatenation as an injection point, and emits a finding that identifies both the tainted parameter and the unsanitized call site. The suggested fix — constant argument arrays or git2go bindings — is attached to the finding, reducing triage-to-patch time from days to hours.
Why Forward Taint Analysis Wins Here
Both vulnerabilities share an anatomy: externally-originating data reaches a dangerous operation through multiple function boundaries. Signature-based rules that match readObject or exec.Command alone produce thousands of false positives across a codebase. Forward taint analysis is selective — it reports only those calls that receive data from a real untrusted source along a feasible path. For ActiveMQ, that means distinguishing the OpenWire transport path from legitimate internal deserialization. For Gogs, it means ignoring exec.Command calls that receive only constant arguments while surfacing the one that concatenates user input. The result is a short, actionable finding list, not a triage backlog.
From Finding to Verified Fix
Security Reviewer pairs each taint-flow finding with a patch suggestion derived from the sink's semantics: allow-list deserialization for Java readObject, exec-argument arrays for Go command invocation. Teams verify the fix by re-scanning the same path; the taint engine confirms the source is no longer connected to the sink, and the finding closes. Compliance evidence — the original trace, the remediation action, and the verification scan — is retained for audit without manual stitching.
Run a Security Reviewer scan on the broker and repository-management services in your stack. If any taint-flow finding references an unguarded readObject or an interpolated exec call, the path from exploit payload to code execution is already open — and your perimeter controls will not stop it.