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
PyPI Explores Prefix Reservation for Organizations Under PEP 752 to Prevent Name Squatting
PEP 752 proposes reserving package name prefixes for organizations on PyPI, allowing control over entire families of related package names rather than individual entries. The change addresses dependency confusion and name squatting risks where attackers register packages with familiar prefixes like google-cloud- or opentelemetry- to exploit user trust. Analysis of over 800,000 PyPI projects by CodeScoring shows that prefixes are rarely controlled by a single owner, with ecosystems like aws- managed by hundreds of accounts. The proposal introduces implicit namespaces and new metadata for clients and proxies while preserving the flat namespace model familiar to Python developers. PEP 755 will define the governance process for granting prefix rights, limiting applications to organizations and requiring clear justification. Existing packages receive backward compatibility exceptions, and the mechanism does not transfer across repositories.
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.