Golem Network Security Review Update

Stanislaw Piwowarczyk -

Over the past few months, we have intensified our security review of the Golem Network software and related internal processes. This was a proactive response to the rapidly changing security landscape all organisations now face in the era of AI-assisted software analysis and vulnerability discovery.

As an open-source project operating infrastructure that runs code across independently operated machines, we believe these developments require us to continuously reassess both our software and the processes used to secure it.

During this work, several vulnerabilities were identified and fixed. This update explains what we found, how we responded, what our investigation has shown so far, and any subsequent precautions we recommend to providers.

Golem Network: Current status

All critical vulnerabilities identified as part of this security review have been fixed.

Affected software versions and vulnerable binaries are no longer distributed, and where necessary, providers running outdated versions were prevented from participating in the Golem computational marketplace.

The vulnerabilities discussed in this update applied only to provider-side software. Requestors were not impacted.

We also investigated with third-party security experts whether the identified vulnerabilities were exploited in production. Based on the evidence available to us, including an independent investigation conducted by Sherlock, we found no evidence that these vulnerabilities were exploited.

Despite the depth of the forensic investigation, we cannot provide absolute certainty that an exploitation never occurred. For this reason, we are also publishing precautionary recommendations for providers below.

Why we initiated the security review

One factor behind this decision was the increasing accessibility and effectiveness of AI-assisted software analysis. Tools that can help legitimate developers identify vulnerabilities can also lower the cost of finding and exploiting weaknesses in publicly available software. This led to our intensified review in July 2026.

We therefore decided to use this moment not only to look more deeply for vulnerabilities, but also to review and improve repositories setup, the way we handle security findings, software releases, updates, and incident response.

As part of these precautions, we temporarily made selected repositories private while this work was underway. This was intended to reduce unnecessary exposure while we investigated and remediated vulnerabilities.

How the review was conducted

The review involved several complementary security efforts:

  • reports submitted by independent Security Researchers and Whitehats through the Golem Bug Bounty Program;
  • security work conducted by @sherlockdefi;
  • security work conducted by Invisible Things Lab;
  • internal bug hunting and code review conducted by Golem Engineers.

It is important to distinguish this process from a security incident discovered through observed exploitation.

The vulnerabilities described in this update were identified through pro-active & deliberate security work, including audits, internal review, testing, and responsible disclosure. We did not begin this process because we had detected an active attack or known compromise of provider machines.

What we found

In total, 76 reports were assessed during the review.

Of these, 36 issues were confirmed and fixed:

  • 1 Critical
  • 6 High
  • 15 Medium
  • 18 Low

A further 36 reports were reviewed and closed without a security-related code change. These concerned expected or accepted design constraints, configuration issues, or defects that did not have a security impact.

Where the issues were found

The confirmed issues were found in the provider daemon (yagna) and in supporting components responsible for file transfers, outbound network controls, local API authorisation, and payment settlement.

The sandbox runtime itself (ya-runtime-vm) was not the source of the critical vulnerability.

All fixes released as part of this review are included in v0.17.10 and later releases, including v0.18.0.

Vulnerability categories

The identified vulnerabilities can be grouped into the following areas:

  • Sandbox file access: Critical. A crafted task request could cause file operations to escape the intended task directory. Depending on the provider setup, this could expose files on the host and potentially allow a path for Remote Code Execution with the permissions of the provider process.
  • Outbound network controls: High. Issues in outbound network restrictions could allow a requestor workload to reach destinations outside those intended by the provider. A related issue could weaken or bypass configured outbound restrictions.
  • Local API authorisation: High, Medium and Low. Several local API endpoints did not consistently enforce which yagna application key was authorised to perform particular operations. This could allow another locally available yagna application key to access sensitive node functions.
  • Payment settlement: High, Medium and Low. Several defects in payment validation and settlement could result in incorrect payment states or shift costs from a requestor to a provider.
  • Denial of service through malformed input: Medium and Low. Six issues involving insufficient input validation could cause the provider or one of its subsystems to terminate unexpectedly. These issues did not expose data, but could interrupt provider availability and earnings.
  • Local machine exposure: Low. Four issues required an attacker to already have some level of access to the provider machine. In those circumstances, the issues could increase the impact of an existing local foothold.

More detailed technical descriptions will be disclosed separately after the appropriate disclosure window.

For each issue, it is also important to distinguish between what a vulnerability could theoretically allow an attacker to do and what we have actually observed in the network.

The existence of a vulnerability does not by itself mean that it was exploited.

How we responded

Once vulnerabilities were confirmed, our priority was to reduce potential exposure while avoiding the unnecessary disclosure of information that could make exploitation easier.

Depending on the vulnerability, our response included:

  • developing and testing fixes;
  • deploying updated versions of provider software;
  • removing vulnerable binaries from download locations;
  • introducing network-level containment measures;
  • preventing providers running outdated or affected versions from participating in the computational marketplace where necessary;
  • preserving relevant network and system information for subsequent forensic analysis;
  • allowing providers time to migrate to patched versions before publishing this information

Publishing actionable exploitation information while vulnerable installations may still be running could have increased the likelihood of abuse. We therefore followed a coordinated disclosure approach, in line with recommendations by security partners: remediate first, provide time for providers to update, investigate possible exploitation, and disclose technical details once doing so no longer creates unnecessary risk.

Investigation into possible exploitation

Following remediation, we asked Sherlock to conduct an independent investigation into whether traces consistent with exploitation of the critical vulnerabilities could be found among a portion of the Golem provider network.

The investigation examined 33 provider setups. Based on the available evidence, the investigation found no evidence that the identified vulnerabilities had been exploited on the systems examined.

Sherlock's detailed methodology, scope, findings, and limitations are described in the accompanying report:

https://files.golem.network/Sherlock-Golem-Provider-Forensic-Report-v1.0.pdf

We want to be precise about what this conclusion means.

Finding no evidence of exploitation is not the same as proving that exploitation was impossible or that it could never have occurred on any machine in the network.

The decentralized nature of Golem means that provider machines are operated independently, and the forensic information available to us is necessarily limited. We therefore believe the appropriate conclusion is that we have found no evidence of exploitation based on the data available to us, rather than making an absolute claim that exploitation never occurred.

Recommendations for providers

Although we have found no evidence that the vulnerabilities were exploited, we recommend that providers take several precautionary steps.

Where applicable, providers should:

  • rotate keys, credentials, API tokens, and other secrets that were stored on or accessible from a machine running an affected provider version;
  • do not run the provider as root on the host;
  • do not run provider containers fully privileged;
  • place provider containers on an isolated network segment;
  • enable host-side network filtering;
  • perform this rotation from a separate, trusted machine;
  • consider moving funds from wallets whose private keys were stored on or accessible from an affected host;
  • consider performing a clean installation of the operating environment
  • review the host for unexpected access, software, processes, or persistence mechanisms;

These recommendations should not be interpreted as evidence that a particular provider machine was compromised.

We understand that many providers operate Golem inside Docker containers, which can provide an additional layer of isolation from the underlying host when configured appropriately. This is different from running Golem directly on a machine that also stores valuable credentials, wallets, private keys, or access to other infrastructure. For that reason, the appropriate precautionary measures may vary depending on each provider's setup and the sensitivity of the assets accessible from the host.

We therefore believe the most responsible approach is to explain what we know and allow providers to take precautions appropriate to their own circumstances.

Improvements to our security processes

We have also used this review as an opportunity to improve the processes surrounding security work within Golem.

Changes already introduced or currently being implemented include improvements to:

  • vulnerability intake and triage;
  • escalation of security-sensitive findings;
  • ownership and accountability for remediation;
  • testing and validation of security fixes;
  • release procedures;
  • rollout of urgent software updates;
  • mechanisms for migrating providers away from vulnerable versions;
  • coordinated vulnerability disclosure;
  • preservation of information relevant to forensic investigations;

Security work is not a one-time exercise, and we expect these processes to continue evolving.

Next steps

We are taking several additional steps to strengthen ongoing security work around Golem.

These include:

  • launching a new security bug bounty program with Sherlock at security.golem.network;
  • continuing regular internal bug-hunting exercises;
  • conducting recurring external security reviews and audits;
  • continuing to work with independent security researchers and whitehats;
  • reviewing Golem's security processes on a regular basis;

More information about the new bug bounty program will follow separately.

Lessons for the wider ecosystem

The security environment for open-source software is changing quickly.

Advances in automated code analysis and AI-assisted vulnerability discovery are increasing capabilities available to both defenders and attackers. For open-source infrastructure projects, particularly those operating decentralized networks, this makes proactive security work increasingly important.

Projects need processes designed to actively search for weaknesses, respond quickly when they are found, update distributed participants safely, and investigate possible impact before publishing information that could create additional risk.

We are applying the lessons from this process not only to Golem Network, but also to other projects within the broader Golem ecosystem.

Acknowledgements

We would like to thank everyone who contributed to this work, including:

  • @only01Essential - Researcher participating in the Golem Bug Bounty Program;
  • @sherlockdefi - Security Experts;
  • Invisible Things Lab - Security Experts;
  • Providers who shared their data with us;
  • Providers who updated their software promptly during the remediation process;
  • Golem Engineering Team.

Security in an open ecosystem depends heavily on people being willing to report problems responsibly. We appreciate everyone who helped us identify, understand, and address these issues.

Reporting security issues

If you believe you have identified a vulnerability in Golem Network, please report it to security@golem.network. Eligible critical security findings may be rewarded.

In the coming weeks, together with @sherlockdefi, we will launch security.golem.network - a dedicated security initiative that will provide clearer guidance on which classes of vulnerabilities are eligible for rewards and make the reporting and submission process more straightforward.

You can also contact us through our Discord.

Please avoid publicly disclosing vulnerabilities before we have had an opportunity to investigate, remediate, and coordinate an appropriate disclosure.

We will continue to share relevant updates as this work progresses, including technical details of the vulnerabilities once they can be disclosed safely.