A critical vulnerability (CVE-2025-32433) exists in Erlang/OTP's SSH implementation, affecting versions prior to 26.2.1 and 25.3.2.6. This flaw allows unauthenticated remote attackers to execute arbitrary code on the server. Specifically, a specially crafted SSH message can trigger the vulnerability during the initial handshake, before authentication occurs, enabling complete system compromise. Users are urged to update their Erlang/OTP installations to the latest patched versions as soon as possible.
NIST is enhancing its methods for evaluating the security of AI agents against hijacking attacks. They've developed a framework with three levels of sophistication, ranging from basic prompt injection to complex exploits involving data poisoning and manipulating the agent's environment. This framework aims to provide a more robust and nuanced assessment of AI agent vulnerabilities by incorporating diverse attack strategies and realistic scenarios, ultimately leading to more secure AI systems.
Hacker News users discussed the difficulty of evaluating AI agent hijacking robustness due to the subjective nature of defining "harmful" actions, especially in complex real-world scenarios. Some commenters pointed to the potential for unintended consequences and biases within the evaluation metrics themselves. The lack of standardized benchmarks and the evolving nature of AI agents were also highlighted as challenges. One commenter suggested a focus on "capabilities audits" to understand the potential actions an agent could take, rather than solely focusing on predefined harmful actions. Another user proposed employing adversarial training techniques, similar to those used in cybersecurity, to enhance robustness against hijacking attempts. Several commenters expressed concern over the feasibility of fully securing AI agents given the inherent complexity and potential for unforeseen vulnerabilities.
NIST has chosen HQC (Hamming Quasi-Cyclic) as the fifth and final public-key encryption algorithm to standardize for post-quantum cryptography. HQC, based on code-based cryptography, offers small public key and ciphertext sizes, making it suitable for resource-constrained environments. This selection concludes NIST's multi-year effort to standardize quantum-resistant algorithms, adding HQC alongside the previously announced CRYSTALS-Kyber for general encryption, CRYSTALS-Dilithium, FALCON, and SPHINCS+ for digital signatures. These algorithms are designed to withstand attacks from both classical and quantum computers, ensuring long-term security in a future with widespread quantum computing capabilities.
HN commenters discuss NIST's selection of HQC, expressing surprise and skepticism. Several highlight HQC's vulnerability to side-channel attacks and question its suitability despite its speed advantages. Some suggest SPHINCS+ as a more robust, albeit slower, alternative. Others note the practical implications of the selection, including the need for hybrid approaches and the potential impact on existing systems. The relatively small key and ciphertext sizes of HQC are also mentioned as positive attributes. A few commenters delve into the technical details of HQC and its underlying mathematical principles. Overall, the sentiment leans towards cautious interest in HQC, acknowledging its strengths while emphasizing its vulnerabilities.
A vulnerability in Microsoft Partner Center (partner.microsoft.com) allowed unauthenticated users to access internal resources. Specifically, improperly configured Azure Active Directory (Azure AD) application and service principal permissions enabled unauthorized access to certain Partner Center APIs. This misconfiguration potentially exposed sensitive business information related to Microsoft partners. Microsoft addressed the vulnerability by correcting the Azure AD application and service principal permissions to prevent unauthorized access.
HN users discuss the lack of detail in the CVE report for CVE-2024-49035, making it difficult to assess the actual impact. Some speculate about the potential severity, ranging from trivial to highly impactful depending on the specific exposed data and functionality. The vagueness also raises questions about Microsoft's disclosure process and the potential for more serious underlying issues. Several commenters note the irony of a vulnerability on a partner security portal, highlighting the difficulty of maintaining perfect security even for organizations focused on it. One user questions the use of "unauthenticated access" in the title, suggesting it might be misleading without knowing what level of access was granted.
Optical frequency combs are extremely precise tools that measure light frequency, analogous to a ruler for light waves. They consist of millions of precisely spaced laser lines that span a broad spectrum, resembling the teeth of a comb. This structure allows scientists to measure optical frequencies with extraordinary accuracy by comparing them to the known frequencies of the comb's "teeth." This technology has revolutionized numerous fields, including timekeeping, by enabling the creation of more accurate atomic clocks, and astronomy, by facilitating the search for exoplanets and measuring the expansion of the universe. It also has applications in telecommunications, chemical sensing, and distance measurement.
Hacker News users discussed the applications and significance of optical frequency combs. Several commenters highlighted their use in extremely precise clocks and the potential for advancements in GPS technology. Others focused on the broader scientific impact, including applications in astrophysics (detecting exoplanets), chemical sensing, and telecommunications. One commenter even mentioned their surprising use in generating arbitrary waveforms for radar. The overall sentiment reflects appreciation for the technological achievement and its potential for future innovation. Some questioned the practical near-term applications, particularly regarding improved GPS, due to the size and cost of current comb technology.
NIST's Standard Reference Material (SRM) 2387, peanut butter, isn't for spreading on sandwiches. It serves as a calibration standard for laboratories analyzing food composition, ensuring accurate measurements of nutrients and contaminants like aflatoxins. This carefully blended and homogenized peanut butter provides a consistent benchmark, allowing labs to verify the accuracy of their equipment and methods, ultimately contributing to food safety and quality. The SRM ensures that different labs get comparable results when testing foods, promoting reliable and consistent data across the food industry.
Hacker News users discuss NIST's standard reference peanut butter (SRMs 2387 and 2388). Several commenters express amusement and mild surprise that such a standard exists, questioning its necessity. Some delve into the practical applications, highlighting its use for calibrating analytical instruments and ensuring consistency in food manufacturing and testing. A few commenters with experience in analytical chemistry explain the importance of reference materials, emphasizing the difficulty in creating homogenous samples like peanut butter. Others discuss the specific challenges of peanut butter analysis, like fat migration and particle size distribution. The rigorous testing procedures NIST uses, including multiple labs analyzing the same batch, are also mentioned. Finally, some commenters joke about the "dream job" of tasting peanut butter for NIST.
Summary of Comments ( 11 )
https://news.ycombinator.com/item?id=43716526
Hacker News users discuss the severity and impact of the Erlang/OTP SSH vulnerability. Some highlight the potential for widespread exploitation given Erlang's usage in telecom infrastructure and distributed systems. Several commenters question the assigned CVSS score of 9.8, finding it surprisingly high for a vulnerability that requires non-default configuration (specifically enabling password authentication). The discussion also touches on the practical implications of the vulnerability, acknowledging that while serious, exploitation might be limited by the need for open SSH ports and enabled password logins. Others express concern about the potential for nested exploitation, as vulnerable Erlang systems might host other exploitable services. Finally, some users note the responsible disclosure and patching process.
The Hacker News post titled "Unauthenticated Remote Code Execution in Erlang/OTP SSH" (https://news.ycombinator.com/item?id=43716526) has several comments discussing the vulnerability (CVE-2025-32433).
Several commenters highlight the severity of the vulnerability, being an unauthenticated remote code execution flaw. One user points out the particularly dangerous combination of this being a pre-auth vulnerability and Erlang's frequent use in distributed systems, increasing the potential attack surface. They mention that distributed Erlang systems often run with minimal firewalling, making them easier targets.
Another commenter notes that exploitation is straightforward, quoting the NIST advisory that "Successful exploitation of this vulnerability requires only sending a crafted SSH message." This emphasizes the low barrier to entry for potential attackers.
Discussion also revolves around the practical impact. One user questions how many publicly exposed Erlang SSH servers exist, suggesting that while serious, the impact might be limited depending on the prevalence of such deployments. This prompts another commenter to mention that while direct SSH access to Erlang nodes might be less common, many systems likely use distributed Erlang for backend communication, which could be vulnerable.
A commenter with experience in securing Erlang systems suggests that the vulnerability reinforces the importance of employing robust network security measures, like firewalls and VPNs, even within internal networks. They highlight that assuming internal networks are safe is a dangerous misconception.
There's some discussion of the technical details. One user dives deeper into the mechanism of the vulnerability, explaining that it arises from the way the
ssh_packet_set_size/1
function handles size limits before authentication, allowing malicious actors to bypass checks and execute arbitrary code.Finally, several commenters express concern about the vulnerability's potential to affect critical infrastructure and industrial control systems, given Erlang's presence in those sectors. One user speculates about the potential for this vulnerability to be exploited in targeted attacks.