<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Cybersecurity on moltenbit</title>
		<link>https://moltenbit.net/tags/cybersecurity/</link>
		<description>Recent content in Cybersecurity on moltenbit</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Tue, 30 Jun 2026 00:00:00 +0200</lastBuildDate>
		
			<atom:link href="https://moltenbit.net/tags/cybersecurity/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Auditing OpenReception: 16 CVEs in an end-to-end encrypted appointment booking platform</title>
				<link>https://moltenbit.net/posts/auditing-openreception/</link>
				<pubDate>Tue, 30 Jun 2026 00:00:00 +0200</pubDate>
				<guid>https://moltenbit.net/posts/auditing-openreception/</guid>
				<description>&lt;p&gt;OpenReception is an open-source appointment booking platform aimed at medical practices, with a self-hosted edition and a commercially hosted multi-tenant version. Its 1.0 release was covered as an open-source alternative to commercial schedulers like Doctolib by &lt;a href=&#34;https://www.heise.de/en/news/OpenReception-1-0-Open-source-appointment-scheduling-for-doctor-s-offices-ready-11278805.html&#34;&gt;heise&lt;/a&gt; and &lt;a href=&#34;https://www.golem.de/news/openreception-offene-doctolib-alternative-ist-fertig-2605-208278.html&#34;&gt;Golem&lt;/a&gt;. Its selling point is end-to-end encryption: patient data is supposed to stay readable only to the staff it is meant for, while the server holds ciphertext it cannot decrypt. A single instance can host many independent practices, and it ships as a SvelteKit application backed by PostgreSQL.&lt;/p&gt;&#xA;&lt;p&gt;I audited the released code shortly after the 1.0 line shipped and ran a local instance from the official docker-compose to validate findings. Over the audit I reported 16 vulnerabilities. All of them were assigned CVEs, four were rated Critical, and all were fixed before public disclosure on 2026-05-20.&lt;/p&gt;&#xA;&lt;p&gt;Two of the four hand an attacker full administrative control, one lets them log in as anyone, and the last quietly defeats the encryption the whole product is built on.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Bypassing Zammad&#39;s AI text tool authorization via REST API (CVE-2026-34782 / CVE-2026-34837)</title>
				<link>https://moltenbit.net/posts/bypassing-zammad-ai-text-tool-authorization-via-rest-api/</link>
				<pubDate>Wed, 08 Apr 2026 12:00:00 +0100</pubDate>
				<guid>https://moltenbit.net/posts/bypassing-zammad-ai-text-tool-authorization-via-rest-api/</guid>
				<description>&lt;p&gt;Zammad 7.0 shipped in March 2026 with a set of new AI features, including customizable &amp;ldquo;text tools&amp;rdquo; that let agents use LLM-powered writing assistance within tickets. Admins can restrict these tools to specific groups, so only the Sales team gets the Sales prompt, and so on.&lt;/p&gt;&#xA;&lt;p&gt;I audited the 7.0 codebase shortly after release and found two independent authorization failures in the REST endpoint used to execute AI text tools. One bug let an agent invoke tools outside their allowed group scope. The second let the same endpoint resolve unauthorized context objects into the prompt template. As a result, data from tickets outside the agent&amp;rsquo;s access scope could end up in the AI prompt and potentially in the returned model output.&lt;/p&gt;&#xA;&lt;p&gt;Zammad patched this in 7.0.1. The findings resulted in two CVEs: &lt;a href=&#34;https://github.com/zammad/zammad/security/advisories/GHSA-96r7-29c8-2j7q&#34;&gt;CVE-2026-34782&lt;/a&gt; for the text tool authorization bypass and &lt;a href=&#34;https://github.com/zammad/zammad/security/advisories/GHSA-89vv-6639-wcv8&#34;&gt;CVE-2026-34837&lt;/a&gt; for the context data IDOR.&lt;/p&gt;&#xA;&lt;p&gt;A third finding from the same audit, a CSRF in OAuth callback endpoints (&lt;a href=&#34;https://github.com/zammad/zammad/security/advisories/GHSA-mfwp-hx66-626c&#34;&gt;CVE-2026-34721&lt;/a&gt;), was also patched in 7.0.1 and backported to 6.5.4, but is not covered in this post.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Bypassing Wazuh&#39;s UNC Mitigation in Windows OSQuery via \\?\UNC\ (CVE-2025-30201 / GHSA-x697-jf34-gp5x)</title>
				<link>https://moltenbit.net/posts/wazuh-unc-mitigation-bypass-cve-2025-30201/</link>
				<pubDate>Tue, 17 Mar 2026 12:00:00 +0100</pubDate>
				<guid>https://moltenbit.net/posts/wazuh-unc-mitigation-bypass-cve-2025-30201/</guid>
				<description>&lt;p&gt;Wazuh mitigated a NetNTLMv2 hash leakage (&lt;a href=&#34;https://nvd.nist.gov/vuln/detail/CVE-2025-30201&#34;&gt;CVE-2025-30201&lt;/a&gt; / &lt;a href=&#34;https://github.com/wazuh/wazuh/security/advisories/GHSA-x697-jf34-gp5x&#34;&gt;GHSA-x697-jf34-gp5x&lt;/a&gt;) issue caused by allowing classic UNC paths (e.g., &lt;code&gt;\\server\share&lt;/code&gt;) in centrally managed Windows agent configuration. The core risk is that when a attacker controlled domain-joined Windows agent accesses a remote SMB path, Windows may perform NTLM authentication to that server, allowing an attacker to capture the machine account&amp;rsquo;s NetNTLMv2 hash.&lt;/p&gt;&#xA;&lt;p&gt;In follow-up testing on &lt;strong&gt;Wazuh 4.14.1&lt;/strong&gt;, &lt;a href=&#34;https://github.com/wazuh/wazuh/security/advisories/GHSA-5g2v-99vr-3hgw&#34;&gt;I found&lt;/a&gt; that the mitigation could still be bypassed in the &lt;strong&gt;OSQuery&lt;/strong&gt; configuration: classic UNC paths were blocked, but &lt;strong&gt;extended-length UNC paths&lt;/strong&gt; using the &lt;code&gt;\\?\UNC\&lt;/code&gt; prefix were accepted for OSQuery&amp;rsquo;s &lt;code&gt;log_path&lt;/code&gt; and &lt;code&gt;config_path&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;The CVE has seen bince been extended to cover the bypass.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Detecting the Notepad&#43;&#43; Supply Chain Attack: A PowerShell Triage Script</title>
				<link>https://moltenbit.net/posts/notepad-supply-chain-attack-triage-script/</link>
				<pubDate>Wed, 04 Feb 2026 12:00:00 +0100</pubDate>
				<guid>https://moltenbit.net/posts/notepad-supply-chain-attack-triage-script/</guid>
				<description>A PowerShell-based triage script to check systems for indicators of compromise related to the Notepad++ supply chain attack attributed to Lotus Blossom APT.</description>
			</item>
	</channel>
</rss>
