Go Library fsnotify: Supply Chain Alarms After Access Changes

A widely used Go library, fsnotify, is now central to a significant supply chain security concern. This follows a sudden change in its maintainer access, which has triggered widespread alarm within the open source community.

The project provides cross-platform filesystem notifications for applications running on Windows, Linux, macOS, BSD, and illumos. Contributors were removed from its GitHub organization without public explanation, and users could not immediately tell whether the changes were routine housekeeping or something far more serious.

The anxiety was understandable given the library’s footprint. According to GitHub data, fsnotify has over 10,700 stars, 969 forks, and more than 321,000 dependent projects.

It sits deep in the software stack, underneath developer tools, command-line interfaces, development servers, and infrastructure pipelines. When uncertainty arises around who can push changes to a library that critical, the effect moves downstream almost instantly.

Researchers at Socket.dev followed the incident closely and noted that the situation carried all the surface signals of a potential supply chain compromise. A popular dependency, recent releases, changed maintainer access, a deleted public post, and unclear authority over the release pipeline created a pattern that looked troubling from the outside, even without confirmed evidence of malicious code.

The incident came to light when Go developer Yasuhiro Matsumoto, known online as mattn, posted to X saying he had been removed from the fsnotify GitHub organization. His post, written in Japanese and later deleted, described being scolded for contributing independently and finding that even the original author had been removed. Once translated and shared, that post sent users scrambling to check release histories and evaluate forks.

Popular Go Library fsnotify Raises Supply Chain Alarms

Grafana Staff Developer Advocate Oshi Yamaguchi opened a GitHub issue flagging the changes, noting that fsnotify is embedded in major open source projects and that downstream users needed clearer answers. The issue drew significant community attention and put pressure on maintainer Martin Tournoij to explain what had happened.

Tournoij responded directly in the GitHub thread, pushing back on the takeover framing. He said the removed accounts held commit rights for historical reasons but had never functioned as active maintainers in any meaningful sense. He argued that recent changes had been merged too quickly, lacked sufficient review across supported platforms, and risked undoing years of careful cleanup work.

A connected trigger was a change to the project’s funding file. Tournoij said Matsumoto committed a sponsorship update directly to the main branch, early in his involvement and without prior discussion. He described this as one of the key reasons for revoking access. Matsumoto later acknowledged the funding file change was a mistake and apologized, while clarifying that his deleted post contained errors, including a wrong claim that the original author had also lost access.

Supply Chain Fears and the Kubernetes Response

The concern quickly reached users further down the stack. A Kubernetes GitHub issue titled “fsnotify/fsnotify: Healthy or not?” called for the project to be watched carefully and suggested evaluating forks if the situation did not stabilize. Matsumoto had also created a separate repository called gofsnotify/fsnotify after losing access, which Kubernetes contributors flagged as something to monitor.

Docker principal software engineer Sebastiaan van Stijn noted that libraries like fsnotify sit low enough in the stack to be forgotten, and that tools like Dependabot make it easy for projects to update dependencies without much scrutiny. His comment captured exactly how a supply chain attack could move silently through a widely trusted library.

Socket.dev analysts pointed out that the early stages of a supply chain compromise and a maintainer dispute look nearly identical from the outside. Both can involve unexpected releases, shifting access, and conflicting public statements.

The xz-utils backdoor is a recent reminder that the threat is real, making developers far more cautious about unusual activity in foundational libraries. Security teams are encouraged to monitor maintainer activity in critical dependencies, verify release histories during disputes, and evaluate forks when project governance becomes unclear.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.