Suspicious Certificate Issuer Detected in MAX Messenger Windows Update Package
A security researcher has reported an unusual change in the code signing certificate used for the MAX messenger desktop client on Windows during its August update cycle.
The original installer MAX.msi and previous updates were consistently signed by Communication Platform LLC, matching the publisher information shown by Windows User Account Control. In the August update, triggered via the client's built-in check, the signer suddenly appeared as an unknown individual named Konstantin Syomochkin.
Background and Observations
The researcher noted that the certificate for Konstantin Syomochkin was issued only two weeks after the latest EU sanctions package. The individual is listed as residing in Astana, Kazakhstan, with prior mentions as an Android developer on Stack Overflow and at the Mobius 2023 Spring conference, but no clear affiliation with the VK team in employee lists.
Direct downloads of version 26.23.0 from the official MAX site for both standard and Yandex-branded MSI files showed the expected company signature. In contrast, the client-initiated update package (version 26.27.3) carried the private certificate and was smaller in size.
Potential Supply Chain Implications
The researcher suggests the anomaly could stem from an emergency workaround after sanctions forced certificate revocation by authorities such as GlobalSign, similar to actions taken in June. All download requests appear to route through Mail.ru trackers to endpoints under download.cdn.oneme.ru.
Because the mismatch could indicate either an internal signing change or external interference in the update delivery chain, the update was not installed. The case has been shared publicly to prompt verification by the VK team responsible for the messenger.
Related articles
LiteLLM Supply Chain Poisoning Exposes 195TB of Credentials Across 2500 Organizations
A detailed forensic report from CloudSEK and Hudson Rock reveals that attackers compromised the LiteLLM CI/CD pipeline by poisoning the Trivy security scanner dependency. The malicious Trivy tag allowed theft of PyPI publishing tokens, leading to the upload of tainted LiteLLM versions 1.82.7 and 1.82.8. Within a 40-minute attack window these packages were downloaded over 119,000 times, exfiltrating 195TB of credentials including AWS, Azure, GCP keys, GitHub tokens, SSH keys, Kubernetes configs, and AI provider API keys. NVIDIA and multiple other major technology firms were confirmed among the victims. The incident highlights critical weaknesses in dependency pinning practices and the absence of automated detection for malicious package behavior on PyPI. Experts warn that AI infrastructure components are becoming high-value targets for future supply-chain campaigns.
Linux Foundation Report Reveals Why Companies Fork Open Source Projects and Maintain Internal Patches
A new Linux Foundation Research study of 567 IT professionals shows that organizations actively modify open source components rather than using them unchanged. While 72% contribute back to projects in some form, many maintain internal forks due to missing features, integration needs, security timelines, and regulatory requirements. The average organization supports 86 internal forks, consuming over 5,000 hours per release cycle. The largest gaps between business-critical technologies and actual contributions appear in programming languages and databases. The findings highlight growing supply-chain risks when internal branches diverge from upstream projects without proper tracking of patches and commits.
Where Secrets Really End Up in Docker Images: Testing 8 Common Methods
A detailed analysis of eight different approaches for handling secrets during Docker image builds reveals that most methods leave sensitive data exposed in layers, configuration files, or build history. Experiments conducted on Ubuntu 24.04.1 LTS with Docker Engine 29.1.3 and BuildKit v0.26.2 showed that simply using RUN rm after COPY or overwriting files fails to remove secrets from immutable layers. Environment variables via ENV and build arguments via ARG both persist in image metadata and history. Only BuildKit Secrets with --mount=type=secret and multi-stage builds that avoid copying secrets into the final stage successfully prevent leakage. The study demonstrates that secrets can be extracted from saved images without running any containers. Developers are advised to adopt these two secure patterns to protect credentials in container supply chains.
Mozilla Revokes GPG Signing Key After Accidental Upload to Private GitHub Repository
Mozilla has replaced the GPG key used to sign certain Firefox and Thunderbird builds following an accidental exposure of the unencrypted secret key in a private GitHub repository. The key was intended for signing Linux archives, RPM packages, and checksum files, raising theoretical risks of supply-chain attacks through forged installers. Company audits found no evidence of external misuse, as repository access was limited to a small group of employees who already held legitimate access to the key. Most users require no action, though those manually verifying GPG signatures must import the new key along with revocation data for the old one. Linux administrators installing Firefox via RPM packages on distributions such as Fedora, RHEL, Rocky Linux, AlmaLinux, openSUSE, and SUSE may need to manually update the key to avoid installation failures. Thunderbird users are unaffected by the RPM issue since no official RPM packages are released for the email client. The new key remains valid until August 5, 2028, with public details available in updated KEY files and on keys.openpgp.org.