--- title: "Curious Case of Embedded Executable in a Newly Introduced Transitive Dependency" description: "A routine dependency upgrade introduced a suspicious transitive dependency with an embedded executable. While manual analysis confirmed it wasn't malicious, this incident highlights the implicit trust we place in open source code and how attackers exploit the software supply chain through seemingly innocent dependency changes." url: "https://safedep.io/blog/curious-case-of-dependency-change-with-embedded-binary-stringish" author: "SafeDep Team" published: "2025-10-27" --- # Curious Case of Embedded Executable in a Newly Introduced Transitive Dependency ## TL;DR This is a story of a new open source package introduced as a transitive dependency during a regular dependency upgrade. The package was flagged as suspicious due to an embedded executable. However, manual analysis confirmed that it is not malicious. This incident highlights the fact that significant volume of code, in any software, is introduced through the open source software supply chain, especially through transitive dependencies that are outside practical control of downstream software consumers. The question remains: **How to trust code from open sources that are a major part of any software** ## Discovery At SafeDep we dogfood our own products. More recently, the [GitHub App](https://github.com/apps/safedep) for protecting against malicious open source packages. While performing a regular dependency upgrade chore, we came across a very interesting real life gotcha in a pull request [xbom/51](https://github.com/safedep/xbom/pull/51). The GitHub App flagged a suspicious package. ![xbom SafeDep GitHub App Report](https://safedep.io/_next/static/immutable/media/safedep-xbom-stringish-package-scan.3j4frjt6tgzw-.png) ## Analysis On inspecting further, [github.com/clipperhouse/stringish @ v0.1.1](https://github.com/clipperhouse/stringish) Go module was flagged as suspicious. The pull request in question was raised with following intentional changes: - Go dependency upgrades using `go get -u` - `Dockerfile` base image update for Go 1.25.2 builder image **Note**: The pull request in question is available at [xbom/51](https://github.com/safedep/xbom/pull/51) Surely no new dependency was intentionally added. When an unknown dependency was flagged as suspicious, we almost certainly assumed it to be in a transitive dependency. The immediate response was to identify the package relationships through which this particular Go module was introduced. ```txt go mod why github.com/clipperhouse/stringish ``` The output shows the path in the dependency graph through which `github.com/clipperhouse/stringish` was introduced ``` # github.com/clipperhouse/stringish github.com/safedep/xbom/pkg/reporter github.com/jedib0t/go-pretty/v6/text github.com/mattn/go-runewidth github.com/clipperhouse/uax29/v2/graphemes github.com/clipperhouse/stringish ``` A quick `git diff` confirmed that the last 2 dependencies are newly introduced: ``` git diff main | grep -i clipperhouse ``` ``` + github.com/clipperhouse/stringish v0.1.1 // indirect + github.com/clipperhouse/uax29/v2 v2.3.0 // indirect ``` But the version of `github.com/mattn/go-runewidth` was updated ``` - github.com/mattn/go-runewidth v0.0.16 // indirect + github.com/mattn/go-runewidth v0.0.19 // indirect ``` At this point, it was pretty clear that the dependency change was introduced between `v0.0.16` and `v0.0.19` of `github.com/mattn/go-runewidth` package. We confirmed this: ``` git clone https://github.com/mattn/go-runewidth /tmp/go-runewidth && \ cd /tmp/go-runewidth && \ git diff v0.0.16...v0.0.19 -- go.mod ``` ```diff diff --git a/go.mod b/go.mod index 62dba1b..7dae1f3 100644 --- a/go.mod +++ b/go.mod @@ -1,5 +1,5 @@ module github.com/mattn/go-runewidth -go 1.9 +go 1.20 -require github.com/rivo/uniseg v0.2.0 +require github.com/clipperhouse/uax29/v2 v2.2.0 ``` [github.com/rivo/uniseg](https://github.com/rivo/uniseg), a project with 600+ stars and 8 contributors was replaced with [github.com/clipperhouse/uax29](https://github.com/clipperhouse/uax29) which is built and maintained by an individual developer. `github.com/clipperhouse/uax29@v2` in turn depends on `github.com/clipperhouse/stringish`, a package that was published only two weeks back. While single developer projects are not a vulnerability in itself, but recently published package with very few published versions included in transitive dependency matches common attacker TTPs that we have seen in various open source software supply chain attacks in the recent past. The following diagram describe the path through which the suspicious package was introduced. ![Dependency Change](https://safedep.io/_next/static/immutable/media/xbom-stringish-dep.43drixzzf3_39.png) ### Why Flagged? The automated analysis report is available [here](https://platform.safedep.io/community/malysis/01K8NS64EQ4D6Q8MKC1EDHYT53). The key reason due to which the package was flagged as suspicious: 1. Recently released package with fewer versions 2. **Embedded executable** `github.com/clipperhouse/stringish@v0.1.1/utf8/utf8.test` ```bash stringish/utf8 on  HEAD (068e024) via 🐹 v1.24.3 ❯ file utf8.test utf8.test: Mach-O 64-bit executable arm64 ``` ### Is it a malware? No. `github.com/clipperhouse/stringish@v0.1.1` is not a malware. We confirm this in following ways: 1. Using [xbom](https://github.com/safedep/xbom) to scan for program capabilities 2. Manual source code review Firstly, `xbom`, a tool that checks for code capabilities (such as process execution) through static code analysis, did not find any risky code capabilities. Manual analysis also did not find any reference to the `utf8.test` file. In fact, there was no reference found for the `utf8.test` file at all due to which [stringish/issues/1](https://github.com/clipperhouse/stringish/issues/1) was raised to discuss possibility of removing binary executable from Go module repository. ## Conclusion This is not a case of malicious package. But this incident resembles multiple malicious packages that we have analysed in the past such as [llm-oracle malicious npm package](https://safedep.io/malicious-oss-package-analysis-llm-oracle/). In fact, introducing unused binary packages or executables resembles the maintainer led attack pattern in [xz incident](https://en.wikipedia.org/wiki/XZ_Utils_backdoor). While there is no evidence of malicious intent in this specific case, the fact remains, open source code is adopted with implicit trust today. This behavior is exploited by introducing malicious code through the open source software supply chain. While code analysis remains one of the reliable methods of protecting against such attacks, such analysis has its limits. Software development teams need to be aware of this risk and take appropriate measures to protect themselves. ## Reference - https://github.com/clipperhouse/stringish/issues/1 - https://github.com/safedep/xbom/pull/51