Despite being a simple, beneficial, and standardized way for security researchers to report vulnerabilities, adoption of security.txt files (as defined by RFC 9116) remains disappointingly low. A 2025 study by Hartwork found that the vast majority of IT companies, including many prominent names, still do not provide a security.txt file on their websites. This lack of adoption hinders responsible vulnerability disclosure and potentially leaves these organizations more susceptible to exploitation, as researchers lack clear reporting channels. The study emphasizes the continued need for greater awareness and adoption of this straightforward security best practice.
Cybersecurity firm Kaspersky Lab has hired Igor Prosvirnin, a former bulletproof hosting provider operating under the moniker "Prospero." Prosvirnin and his company were notorious for harboring criminal operations, including malware distribution and spam campaigns, despite repeated takedown attempts. Kaspersky claims Prosvirnin will work on improving their anti-spam technologies, leveraging his expertise on the inner workings of these illicit operations. This move has generated significant controversy due to Prosvirnin's history, raising concerns about Kaspersky's judgment and potential conflicts of interest.
Hacker News users discuss Kaspersky's acquisition of Prospero, a domain known for hosting malware and spam. Several express skepticism and concern, questioning Kaspersky's motives and the potential implications for cybersecurity. Some speculate that Kaspersky aims to analyze the malware hosted on Prospero, while others worry this legitimizes a malicious actor and may enable Kaspersky to distribute malware or bypass security measures. A few commenters point out Kaspersky's past controversies and ties to the Russian government, furthering distrust of this acquisition. There's also discussion about the efficacy of domain blacklists and the complexities of cybersecurity research. Overall, the sentiment is predominantly negative, with many users expressing disbelief and apprehension about Kaspersky's involvement.
A recent study reveals that CAPTCHAs are essentially a profitable tracking system disguised as a security measure. While ostensibly designed to differentiate bots from humans, CAPTCHAs allow companies like Google to collect vast amounts of user data for targeted advertising and other purposes. This system has cost users a staggering amount of time—an estimated 819 billion hours globally—and has generated nearly $1 trillion in revenue, primarily for Google. The study argues that the actual security benefits of CAPTCHAs are minimal compared to the immense profits generated from the user data they collect. This raises concerns about the balance between online security and user privacy, suggesting CAPTCHAs function more as a data harvesting tool than an effective bot deterrent.
Hacker News users generally agree with the premise that CAPTCHAs are exploitative. Several point out the irony of Google using them for training AI while simultaneously claiming they prevent bots. Some highlight the accessibility issues CAPTCHAs create, particularly for disabled users. Others discuss alternatives, such as Cloudflare's Turnstile, and the privacy implications of different solutions. The increasing difficulty and frequency of CAPTCHAs are also criticized, with some speculating it's a deliberate tactic to push users towards paid "captcha-free" services. Several commenters express frustration with the current state of CAPTCHAs and the lack of viable alternatives.
The FBI and Dutch police have disrupted the "Manipulaters," a large phishing-as-a-service operation responsible for stealing millions of dollars. The group sold phishing kits and provided infrastructure like bulletproof hosting, allowing customers to easily deploy and manage phishing campaigns targeting various organizations, including banks and online retailers. Law enforcement seized 14 domains used by the gang and arrested two individuals suspected of operating the service. The investigation involved collaboration with several private sector partners and focused on dismantling the criminal infrastructure enabling widespread phishing attacks.
Hacker News commenters largely praised the collaborative international effort to dismantle the Manipulaters phishing gang. Several pointed out the significance of seizing infrastructure like domain names and bulletproof hosting providers, noting this is more effective than simply arresting individuals. Some discussed the technical aspects of the operation, like the use of TOX for communication and the efficacy of taking down such a large network. A few expressed skepticism about the long-term impact, predicting that the criminals would likely resurface with new infrastructure. There was also interest in the Dutch police's practice of sending SMS messages to potential victims, alerting them to the compromise and urging them to change passwords. Finally, several users criticized the lack of detail in the article about how the gang was ultimately disrupted, expressing a desire to understand the specific techniques employed by law enforcement.
A hacker tricked approximately 18,000 aspiring cybercriminals ("script kiddies") by distributing a fake malware builder. Instead of creating malware, the tool actually infected their own machines with a clipper, which silently replaces cryptocurrency wallet addresses copied to the clipboard with the attacker's own, diverting any cryptocurrency transactions to the hacker. This effectively turned the tables on the would-be hackers, highlighting the risks of using untrusted tools from underground forums.
HN commenters largely applaud the vigilante hacker's actions, viewing it as a form of community service by removing malicious actors and their potential harm. Some express skepticism about the 18,000 figure, suggesting it's inflated or that many downloads may not represent active users. A few raise ethical concerns, questioning the legality and potential collateral damage of such actions, even against malicious individuals. The discussion also delves into the technical aspects of the fake builder, including its payload and distribution method, with some speculating on the hacker's motivations beyond simple disruption.
DoubleClickjacking is a clickjacking technique that tricks users into performing unintended actions by overlaying an invisible iframe containing an ad over a legitimate clickable element. When the user clicks what they believe to be the legitimate element, they actually click the hidden ad, generating revenue for the attacker or redirecting the user to a malicious site. This exploit leverages the fact that some ad networks register clicks even if the ad itself isn't visible. DoubleClickjacking is particularly concerning because it bypasses traditional clickjacking defenses that rely on detecting visible overlays. By remaining invisible, the malicious iframe effectively hides from security measures, making this attack difficult to detect and prevent.
Hacker News users discussed the plausibility and impact of the "DoubleClickjacking" technique described in the linked article. Several commenters expressed skepticism, arguing that the described attack is simply a variation of existing clickjacking techniques, not a fundamentally new vulnerability. They pointed out that modern browsers and frameworks already have mitigations in place to prevent such attacks, like the X-Frame-Options header. The discussion also touched upon the responsibility of ad networks in preventing malicious ads and the effectiveness of user education in mitigating these types of threats. Some users questioned the practicality of the attack, citing the difficulty in precisely aligning elements for the exploit to work. Overall, the consensus seemed to be that while the described scenario is technically possible, it's not a novel attack vector and is already addressed by existing security measures.
Researchers discovered a second set of vulnerable internet domains (.gouv.bf, Burkina Faso's government domain) being resold through a third-party registrar after previously uncovering a similar issue with Gabon's .ga domain. This highlights a systemic problem where governments outsource the management of their top-level domains, often leading to security vulnerabilities and potential exploitation. The ease with which these domains can be acquired by malicious actors for a mere $20 raises concerns about potential nation-state attacks, phishing campaigns, and other malicious activities targeting individuals and organizations who might trust these seemingly official domains. This repeated vulnerability underscores the critical need for governments to prioritize the security and proper management of their top-level domains to prevent misuse and protect their citizens and organizations.
Hacker News users discuss the implications of governments demanding access to encrypted data via "lawful access" backdoors. Several express skepticism about the feasibility and security of such systems, arguing that any backdoor created for law enforcement can also be exploited by malicious actors. One commenter points out the "irony" of governments potentially using insecure methods to access the supposedly secure backdoors. Another highlights the recurring nature of this debate and the unlikelihood of a technical solution satisfying all parties. The cost of $20 for the domain used in the linked article also draws attention, with speculation about the site's credibility and purpose. Some dismiss the article as fear-mongering, while others suggest it's a legitimate concern given the increasing demands for government access to encrypted communications.
Summary of Comments ( 1 )
https://news.ycombinator.com/item?id=43235972
Hacker News users generally agreed with the premise that security.txt adoption is disappointingly low, with several expressing frustration at the security industry's failure to implement basic best practices. Some commenters pointed out that even security-focused companies often lack a security.txt file, highlighting a general apathy or ignorance towards the standard. Others discussed the potential downsides of security.txt, such as increased exposure to automated vulnerability scanning and the possibility of it becoming a target for social engineering attacks. A few suggested that the lack of adoption might stem from the perceived lack of clear benefits or fear of legal repercussions for disclosed vulnerabilities. The overall sentiment reflects a concern for the slow uptake of a seemingly simple yet beneficial security measure.
The Hacker News post titled "Most IT companies fail to serve security.txt for RFC 9116 in 2025" generated a moderate number of comments discussing the adoption (or lack thereof) of the security.txt standard. Several commenters expressed a general sentiment of disappointment and frustration with the slow uptake of such a simple, yet beneficial, security practice.
One compelling line of discussion revolved around the practical challenges and perceived lack of incentives for companies to implement security.txt. Some argued that security researchers often find vulnerabilities through means other than those advertised in a security.txt file, therefore diminishing its perceived value for companies. Others countered this point by highlighting the importance of providing a clear and official channel for reporting vulnerabilities, regardless of how they are discovered. This, they argued, can help streamline the vulnerability disclosure process and prevent researchers from resorting to less secure or less desirable methods of contact.
Another commenter pointed out that the absence of security.txt often leads to wasted time and effort for security researchers who have to resort to searching for contact information through various channels, potentially leading to delayed vulnerability disclosures. This reinforces the argument that security.txt benefits both the reporting party and the receiving organization.
The issue of discoverability also arose, with some commenters questioning how effective security.txt is if search engines aren't indexing it reliably. This raised concerns about the practical utility of the standard if it's not easily findable by those who need it.
Finally, a few comments touched upon the potential legal implications of not having a security.txt file, suggesting that in the future, its absence might be considered negligent, especially in regulated industries. This adds another layer of incentive for companies to adopt the standard, moving beyond best practice and towards a potential legal requirement.
While no single comment was overwhelmingly compelling in isolation, the collective discussion painted a picture of a security standard struggling with adoption despite its simplicity and potential benefits. The comments highlighted the tension between the perceived effort required for implementation and the potential benefits, as well as the need for improved discoverability and potential future legal implications that might drive wider adoption.