Overview
LangChainGo, the Go implementation of LangChain, a large language model (LLM) application building framework, has been discovered to contain an arbitrary file read vulnerability. The vulnerability, tracked as CVE-2025-9556, allows for arbitrary file read through the Gonja template engine with Jinja2 syntax. Attackers can exploit this by injecting malicious prompt content to access sensitive files, leading to a server-side template injection (SSTI) attack.
Description
LangChainGo is the Go Programming Language port/fork of LangChain, an open-source orchestration framework for the development of applications that leverage LLMs. LangChainGo uses Gonja for syntax parsing and creating dynamic and reusable prompt templates. Gonja is the Go implementation of Jinja2, a templating engine. Gonja is largely compatable with the the original Python Jinja2 implementation, and supports Jinja2 syntax.
As Gonja supports Jinja2 syntax, an attacker could leverage directives such as % include %, % from %, or % extends % for malicious purposes within LangChainGo. While these directives were meant to be used for building reusable templates, they can also allow an external file to be pulled and read from the server’s filesystem. An attacker could use this to inject malicious template code containing advanced templating directives to read sensitive files such as /etc/password. This results in a server-side template injection vulnerability that can expose sensitive information. This vulnerability is tracked as CVE-2025-9556.
Impact
This vulnerability compromises the confidentiality of the system by enabling arbitrary file read on a server running LangChainGo. By injecting malicious template syntax, an attacker could access sensitive information stored on the victim device. This information can lead to further comprise of the system. In LLM-based chatbot environments that use LangChainGo, attackers would only need access to the prompt to maliciously craft and exploit the prompt.
Solution
The maintainer of LangChainGo has released with new security features to prevent template injection. A new RenderTemplateFS function has been added, which supports secure file template referencing, on top of blocking filesystem access by default. Users of LangChainGo should update to the latest version of the software in order to be protected.
Acknowledgements
Thanks to the reporter, bestlzk. This document was written by Ayushi Kriplani and Christopher Cullen.

Overview
Two local security vulnerabilities have been identified in Sunshine for Windows, version v2025.122.141614 (and likely prior versions). These issues could allow attackers to execute arbitrary code and escalate privileges on affected systems.
Description
Sunshine is a self-hosted game stream host for Moonlight.

CVE-2025-10198 Unquoted Service Path (CWE-428)
Sunshine for Windows installs a service with an unquoted service path. This allows an attacker with local access to place a malicious executable in a directory within the service path (before the legitimate binary), which could then be executed with elevated privileges during system startup or service restart.

CVE-2025-10199 DLL Search-Order Hijacking (CWE-427)
Sunshine for Windows does not properly control the search path for required DLLs. This allows an attacker to place a malicious DLL in a user-writable directory that is included in the PATH environment variable. When the application loads, it may inadvertently load the malicious DLL, resulting in arbitrary code execution.

Impact

CVE-2025-10198 Attackers with local access can escalate privileges to SYSTEM, resulting in full compromise of the affected machine.
CVE-2025-10199 Attackers can execute malicious code in the context of the user running the application.

Solution
Apply an update from the Sunshine project once available.
As mitigation, until a patch is released:

Ensure user-writable directories are not included in the PATH environment variable.

Quote all service paths in Windows service configurations.

Restrict permissions on service-related directories to prevent unauthorized file placement.

Acknowledgements
Thanks to the reporter, Pundhapat Sichamnong. This document was written by Timur Snoke.

Overview
The Amp’ed RF BT-AP 111 Bluetooth Access Point exposes an HTTP-based administrative interface without authentication controls. This allows an unauthenticated remote attacker to gain full administrative access to the device.
Description
The Amp’ed RF BT-AP 111 is a Bluetooth-to-Ethernet bridge that can function as an access point or a Bluetooth gateway. According to the vendor’s website, the device supports Universal Plug and Play (UPnP) on the Ethernet side and acts as a UART Serial device to support up to seven simultaneous Bluetooth connections.
The BT-AP 111 provides a web-based administrative interface over HTTP. However, this interface does not implement any authentication mechanism. As a result, any user with network access to the device’s HTTP port can view and modify the administrative interface. An attacker with such access can alter Bluetooth configurations, network parameters, and other security-related settings.
According to NIST guidance, authentication is an expected baseline security control even for near-field or Bluetooth devices. The NIST Guide to Bluetooth Security (SP 800-121 Rev. 2), defines security levels that require at least authentication (Service Level 2) and preferably authentication and authorization (Service Level 1). More broadly, NIST SP 800-124 Rev. 1 emphasizes that devices should enforce authentication before granting access to configuration or administrative resources. The absence of authentication on the BT-AP 111 administrative web interface is therefore inconsistent with established best practices.
Impact
An attacker with network access (local or remote) to the web interface can gain full administrative control of the device and modify any settings exposed through the interface.
Solution
At this time, CERT/CC has not received a response from the vendor regarding this vulnerability. Since the device cannot be secured with authentication or any access controls, it is recommended that any deployments be restricted to isolated networks that are inaccessible to untrusted users.
Acknowledgements
Thanks to the reporter, Souvik Kandar. This document was written by Timur Snoke.