Web Application | Breaking Cybersecurity News | The Hacker News

A second security flaw impacting the OttoKit (formerly SureTriggers ) WordPress plugin has come under active exploitation in the wild. The vulnerability, tracked as CVE-2025-27007 (CVSS score: 9.8), is a privilege escalation bug impacting all versions of the plugin prior to and including version 1.0.82.  "This is due to the create_wp_connection() function missing a capability check and insufficiently verifying a user's authentication credentials," Wordfence said . "This makes it possible for unauthenticated attackers to establish a connection, which ultimately can make privilege escalation possible." That said, the vulnerability is exploitable only in two possible scenarios - When a site has never enabled or used an application password, and OttoKit has never been connected to the website using an application password before When an attacker has authenticated access to a site and can generate a valid application password Wordfence revealed that it obs...

Well, you shouldn't. It may already be hiding vulnerabilities. It's the modular nature of modern web applications that has made them so effective. They can call on dozens of third-party web components, JS frameworks, and open-source tools to deliver all the different functionalities that keep their customers happy, but this chain of dependencies is also what makes them so vulnerable. Many of those components in the web application supply chain are controlled by a third party—the company that created them. This means that no matter how rigorous you were with your own static code analysis, code reviews, penetration testing, and other SSDLC processes, most of your supply chain's security is in the hands of whoever built its third-party components. With their huge potential for weak spots, and their widespread use in the lucrative ecommerce, financial and medical industries, web application supply chains present a juicy target for cyber attackers. They can target any one of the doz...

Everyone has cybersecurity stories involving family members. Here's a relatively common one. The conversation usually goes something like this:  "The strangest thing happened to my streaming account. I got locked out of my account, so I had to change my password. When I logged back in, all my shows were gone. Everything was in Spanish and there were all these Spanish shows I've never seen before. Isn't that weird?" This is an example of an account takeover attack on a customer account. Typically what happens is that a streaming account is compromised, probably due to a weak and reused password, and access is resold as part of a common digital black market product, often advertised as something like "LIFETIME STREAMING SERVICE ACCOUNT - $4 USD." In the grand scheme of things, this is a relatively mild inconvenience for most customers. You can reset your credentials with a much stronger password, call your bank to issue a new credit card and be back to binge-watching The Crown i...

Businesses know they need to secure their client-side scripts. Content security policies (CSPs) are a great way to do that. But CSPs are cumbersome. One mistake and you have a potentially significant client-side security gap. Finding those gaps means long and tedious hours (or days) in manual code reviews through thousands of lines of script on your web applications. Automated content security policies can help streamline the code review process by first identifying all first- and third-party scripts and the assets they access, and then generating an appropriate content security policy to help better secure the client-side attack surface. There are few developers or AppSec professionals who claim to enjoy deploying CSPs. First, the CSP has to work for the specific web application. Then the team needs to make sure it provides the appropriate level of protection. The CSP also can't conflict with any existing widgets or plugins (or the decision must be made to not deploy the CSP or dea...