Researchers have disclosed technical details on a new AMD processor attack that allows remote code execution inside confidential VMs.
The post New ‘StackWarp’ Attack Threatens Confidential VMs on AMD Processors appeared first on SecurityWeek.
Researchers have disclosed technical details on a new AMD processor attack that allows remote code execution inside confidential VMs.
The post New ‘StackWarp’ Attack Threatens Confidential VMs on AMD Processors appeared first on SecurityWeek.
Vibe coding generates a curate’s egg program: good in parts, but the bad parts affect the whole program.
The post Vibe Coding Tested: AI Agents Nail SQLi but Fail Miserably on Security Controls appeared first on SecurityWeek.
In cybersecurity, vulnerability information sharing frameworks have long assumed that conventional threats exploit flaws in software or systems, and they can be resolved with patches or configuration updates. AI and machine learning (ML) models upend that premise as adversarial attacks, like poisoning and evasion, target the unique way AI models process information. Consequently, the risks for AI systems include tactics like model poisoning (from evasion attacks) in datasets and training, which are not conventional software vulnerabilities. These new vulnerabilities fall outside the scope of traditional cybersecurity taxonomies like the Common Vulnerabilities and Exposures (CVE) Program.
There is a need to bridge the gap between the existing cybersecurity vulnerability sharing structure and burgeoning efforts to catalog security risks to AI systems. Provisions in the White House AI Action Plan, which Palo Alto Networks supports, call for the creation of an AI Information Sharing and Analysis Center (AI-ISAC), reinforcing the importance of addressing that disconnect. This integration is essential, as leveraging the existing, widely adopted cybersecurity infrastructure will be the fastest path to ensuring these new standards are accepted and operationalized.
The global cybersecurity community relies on a mature infrastructure for sharing standardized vulnerability intelligence. Central to this ecosystem is the CVE List, established in 1999 as the authoritative catalog of cybersecurity vulnerabilities. Through CVE IDs and a network of CVE Numbering Authorities (CNAs), this framework enables consistent vulnerability documentation and disclosure.
Similarly, the Common Vulnerability Scoring System (CVSS) provides standardized severity assessments, allowing security teams to prioritize responses. Together with resources like the National Vulnerability Database (NVD) and CISA’s KEV Catalog catalog, these tools form the backbone of global vulnerability management, information sharing and coordinated disclosure.
While this infrastructure has served the cybersecurity community effectively for over two decades, it was designed around traditional threat models that AI systems substantially upend. Attacks on AI systems represent a critical departure from traditional cybersecurity threats as they operate insidiously, subtly corrupting core reasoning processes, causing persistent, systemic failures, some of which only become evident over time. Most traditional cybersecurity tools are not equipped to recognize those breakdowns because they assume deterministic behavior and rules-based logic. AI systems defy those assumptions because AI is probabilistic, not deterministic. Consequently, attacks on AI models may remain hidden for extended periods.
Unlike traditional cybersecurity threats that target code, adversarial AI attacks target the underlying data and algorithms that govern how AI systems learn, reason and make decisions. Consider the following predominant adversarial attack methodologies on machine learning:
The expansion of existing security frameworks and programs is necessary to cover the enumeration, disclosure and downstream management of security risks to AI systems.
In July, the Administration unveiled the AI Action Plan, an innovation-first framework balancing AI advancement with security imperatives. The Plan prioritizes Secure-by-Design AI technologies and applications, strengthened critical infrastructure cybersecurity and protection of commercial and government AI innovations.
Notably, it recommends establishing an AI Information Sharing and Analysis Center (AI-ISAC) to facilitate threat intelligence sharing across U.S. critical infrastructure sectors and encourages sharing known AI vulnerabilities, “tak[ing] advantage of existing cyber vulnerability sharing mechanisms.” These provisions affirm that AI security underpins American leadership in the field and, where possible, should be built upon existing frameworks.
To position the CVE Program for the AI-driven future, Palo Alto Networks is engaging directly with industry and program stakeholders to chart the path forward. Traditionally, the CVE Program serves as an ecosystem-wide central warning system. It provides a unified source of truths for security risks. A security risk catalog and identification system are needed for AI systems, as they currently fall outside the traditional scope of the CVE Program that has focused exclusively on vulnerabilities rather than on malicious components. The historical aperture of the current CVE Program excludes harmful artifacts, such as backdoored AI models or poisoned datasets, which represent fundamentally different attack vectors, in turn creating security blind spots.
The United States leads in AI innovation and must equally lead in securing it. As momentum builds behind the AI Action Plan and the establishment of the AI-ISAC, we have a critical window to shape information sharing frameworks of the future. The goal is to ensure that cybersecurity and AI security infrastructure advance in unison with the technology itself. Integrating new AI vulnerability standards into trusted frameworks like the CVE Program aligns with industry focus and needs. Through proactive, coordinated action, we can unlock AI’s full promise while safeguarding the models that are embedded in the critical systems on which our nation depends.
The post Bridging Cybersecurity and AI appeared first on Palo Alto Networks Blog.

The developer security company has raised a total of more than $84 million in funding.
The post Aikido Security Raises $60 Million at $1 Billion Valuation appeared first on SecurityWeek.
Novee provides continuous AI-driven penetration testing to uncover and address novel vulnerabilities.
The post Novee Emerges From Stealth With $51.5 Million in Funding appeared first on SecurityWeek.
Some attackers are increasingly moving away from simple redirects in favor of more “selective” methods of payload delivery. This approach filters out regular human visitors, allowing attackers to serve malicious content to search engine crawlers while remaining invisible to the website owner.
What did we find?
During a malware investigation, we identified a selective content injection attack inside the main index.php file of a WordPress website.
Instead of always loading WordPress normally, this modified file checks who is visiting the site.
Continue reading Malware Intercepts Googlebot via IP-Verified Conditional Logic at Sucuri Blog.
AI will assist companies in finding their external attack surface, but it will also assist bad actors in locating and attacking the weak points.
The post Cyber Insights 2026: External Attack Surface Management appeared first on SecurityWeek.

Thanks to the convenience of NFC and smartphone payments, many people no longer carry wallets or remember their bank card PINs. All their cards reside in a payment app, and using that is quicker than fumbling for a physical card. Mobile payments are also secure — the technology was developed relatively recently and includes numerous anti-fraud protections. Still, criminals have invented several ways to abuse NFC and steal your money. Fortunately, protecting your funds is straightforward: just know about these tricks and avoid risky NFC usage scenarios.
NFC relay is a technique where data wirelessly transmitted between a source (like a bank card) and a receiver (like a payment terminal) is intercepted by one intermediate device, and relayed in real time to another. Imagine you have two smartphones connected via the internet, each with a relay app installed. If you tap a physical bank card against the first smartphone and hold the second smartphone near a terminal or ATM, the relay app on the first smartphone will read the card’s signal using NFC, and relay it in real time to the second smartphone, which will then transmit this signal to the terminal. From the terminal’s perspective, it all looks like a real card is tapped on it — even though the card itself might physically be in another city or country.
This technology wasn’t originally created for crime. The NFCGate app appeared in 2015 as a research tool after it was developed by students at the Technical University of Darmstadt in Germany. It was intended for analyzing and debugging NFC traffic, as well as for education purposes and experiments with contactless technology. NFCGate was distributed as an open-source solution and used in academic and enthusiast circles.
Five years later, cybercriminals caught on to the potential of NFC relay and began modifying NFCGate by adding mods that allowed it to run through a malicious server, disguise itself as legitimate software, and perform social engineering scenarios.
What began as a research project morphed into the foundation for an entire class of attacks aimed at draining bank accounts without physical access to bank cards.
The first documented attacks using a modified NFCGate occurred in late 2023 in the Czech Republic. By early 2025, the problem had become large scale and noticeable: cybersecurity analysts uncovered more than 80 unique malware samples built on the NFCGate framework. The attacks evolved rapidly, with NFC relay capabilities being integrated into other malware components.
By February 2025, malware bundles combining CraxsRAT and NFCGate emerged, allowing attackers to install and configure the relay with minimal victim interaction. A new scheme, a so-called “reverse” version of NFCGate, appeared in spring 2025, fundamentally changing the attack’s execution.
Particularly noteworthy is the RatOn Trojan, first detected in the Czech Republic. It combines remote smartphone control with NFC relay capabilities, letting attackers target victims’ banking apps and cards through various technique combinations. Features like screen capture, clipboard data manipulation, SMS sending, and stealing info from crypto wallets and banking apps give criminals an extensive arsenal.
Cybercriminals have also packaged NFC relay technology into malware-as-a-service (MaaS) offerings, and reselling them to other threat actors through subscription. In early 2025, analysts uncovered a new and sophisticated Android malware campaign in Italy, dubbed SuperCard X. Attempts to deploy SuperCard X were recorded in Russia in May 2025, and in Brazil in August of the same year.
The direct attack is the original criminal scheme exploiting NFCGate. In this scenario, the victim’s smartphone plays the role of the reader, while the attacker’s phone acts as the card emulator.
First, the fraudsters trick the user into installing a malicious app disguised as a banking service, a system update, an “account security” app, or even a popular app like TikTok. Once installed, the app gains access to both NFC and the internet — often without requesting dangerous permissions or root access. Some versions also ask for access to Android accessibility features.
Then, under the guise of identity verification, the victim is prompted to tap their bank card to their phone. When they do, the malware reads the card data via NFC and immediately sends it to the criminals’ server. From there, the information is relayed to a second smartphone held by a money mule, who helps extract the money. This phone then emulates the victim’s card to make payments at a terminal or withdraw cash from an ATM.
The fake app on the victim’s smartphone also asks for the card PIN — just like at a payment terminal or ATM — and sends it to the attackers.
In early versions of the attack, criminals would simply stand ready at an ATM with a phone to use the duped user’s card in real time. Later, the malware was refined so the stolen data could be used for in-store purchases in a delayed, offline mode, rather than in a live relay.
For the victim, the theft is hard to notice: the card never left their possession, they didn’t have to manually enter or recite its details, and the bank alerts about the withdrawals can be delayed or even intercepted by the malicious app itself.
Among the red flags that should make you suspect a direct NFC attack are:
The reverse attack is a newer, more sophisticated scheme. The victim’s smartphone no longer reads their card — it emulates the attacker’s card. To the victim, everything appears completely safe: there’s no need to recite card details, share codes, or tap a card to the phone.
Just like with the direct scheme, it all starts with social engineering. The user gets a call or message convincing them to install an app for “contactless payments”, “card security”, or even “using central bank digital currency”. Once installed, the new app asks to be set as the default contactless payment method — and this step is critically important. Thanks to this, the malware requires no root access — just user consent.
The malicious app then silently connects to the attackers’ server in the background, and the NFC data from a card belonging to one of the criminals is transmitted to the victim’s device. This step is completely invisible to the victim.
Next, the victim is directed to an ATM. Under the pretext of “transferring money to a secure account” or “sending money to themselves”, they are instructed to tap their phone on the ATM’s NFC reader. At this moment, the ATM is actually interacting with the attacker’s card. The PIN is dictated to the victim beforehand — presented as “new” or “temporary”.
The result is that all the money deposited or transferred by the victim ends up in the criminals’ account.
The hallmarks of this attack are:
NFC relay attacks rely not so much on technical vulnerabilities as on user trust. Defending against them comes down to some simple precautions.




Forty years ago, The Mentor—Loyd Blankenship—published “The Conscience of a Hacker” in Phrack.
You bet your ass we’re all alike… we’ve been spoon-fed baby food at school when we hungered for steak… the bits of meat that you did let slip through were pre-chewed and tasteless. We’ve been dominated by sadists, or ignored by the apathetic. The few that had something to teach found us willing pupils, but those few are like drops of water in the desert.
This is our world now… the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt-cheap if it wasn’t run by profiteering gluttons, and you call us criminals. We explore… and you call us criminals. We seek after knowledge… and you call us criminals. We exist without skin color, without nationality, without religious bias… and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it’s for our own good, yet we’re the criminals.
Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

In an era marked by escalating cyber threats and evolving risk landscapes, organisations face mounting pressure to strengthen their security posture whilst maintaining seamless user experiences. At Thales, we recognise that robust security must be foundational – embedded into products and services by design, not bolted on as an afterthought. This principle underpins our commitment to the U.S. Cybersecurity and Infrastructure Security Agency (CISA)’s Secure-by-Design pledge, which calls on software manufacturers to establish security features like multi-factor authentication (MFA) as standard across their product portfolios.
As digital transformation accelerates and attack surfaces expand, the gap between security capabilities and emerging threats continues to widen. According to the 2025 Thales Data Threat Report, organisations are grappling with unprecedented challenges: 69% regard the fast-moving ecosystem as the most concerning GenAI security risk, whilst 83% report that strong MFA is used more than 40% of the time. This indicates both progress and significant opportunity for improvement. These findings underscore a critical reality: whilst security tools and technologies have advanced, comprehensive deployment and consistent enforcement remain essential challenges that demand immediate attention.
This blog examines the pivotal role of multi-factor authentication in modern cybersecurity strategies. We explore the fundamentals of MFA, analyse the evolving threat landscape that necessitates its adoption, and provide practical guidance on implementation. Whether you are a security professional seeking to strengthen your organisation’s defences or an individual user looking to protect personal accounts, this resource offers the insights and actionable steps needed to embrace MFA with confidence and rigour.
Multi-factor authentication verifies your identity using two different forms of identification. Typically this involves something you know (like a password) and something you have (like a code on your phone). Think of it like using an ATM: you need both your bank card and your PIN to withdraw cash.
This dual-layer approach creates a significant barrier for attackers. Even if someone steals your password, they still can’t log in without that second factor. It’s elegantly simple, yet remarkably powerful – your password alone is no longer enough to unlock the door.
Cyberattacks have grown increasingly sophisticated, with stolen passwords at the heart of many breaches. According to the 2023 Verizon Data Breach Investigations Report, nearly 49% of data breaches involved the use of stolen credentials.
MFA directly addresses this vulnerability. Our own research at Thales demonstrates the critical importance of strong authentication measures. According to the 2025 Thales Data Threat Report, 83% of organisations report that strong MFA is used more than 40% of the time, yet significant challenges remain in achieving comprehensive deployment. This data underscores both the growing recognition of MFA’s importance and the continued need for organisations to strengthen their authentication posture.
Furthermore, our 2025 Digital Trust Index – Third-Party Edition reveals a concerning reality: 40% of users reset passwords once or twice a month, highlighting the inherent weakness of password-only authentication systems. These frequent password resets not only frustrate users but also create security vulnerabilities that MFA effectively mitigates.
MFA thwarts the most prevalent attack techniques:
Brute-force and credential stuffing attacks: These automated attacks become practically futile with MFA enabled because guessing the password isn’t enough to break in.
Phishing attacks: Even if you unwittingly hand over your password to a phisher, they still can’t access your account without the one-time code or second factor that MFA requires.
It’s no surprise that CISA’s Secure-by-Design guidelines explicitly call for making MFA a built-in, default security feature. In today’s threat landscape, MFA has evolved from a nice-to-have extra to an essential safeguard.
At Thales, we build security into our products by design, baked into our products and services. Our commitment to CISA’s Secure-by-Design pledge is reflected in how we develop features like MFA.
We already implement robust MFA across our cloud services to help safeguard your accounts and data. By requiring two forms of identification to access the Thales Cloud Security Console, we add an extra layer of protection that makes it “much harder for unauthorised users to access sensitive information”. This significantly reduces the risk of breaches and builds trust.
Thales’ approach recognises shared responsibility. “Security by default” means we provide secure settings and features right out of the box. However, security is also a partnership – we provide the tools, whilst you play a crucial role by using them.
We’ve made MFA available and straightforward to configure, and we actively encourage customers to use advanced authentication methods. Whilst MFA might not be mandated on all accounts by default today, we strongly recommend that you activate it. By choosing to enable MFA now, you’re not only protecting yourself immediately but also aligning with best practices that Thales and the cybersecurity community advocate globally.
Enabling multi-factor authentication on your Thales account is quick and straightforward. Here’s how:
That’s it! You’ve added a powerful extra layer of security in just a few minutes.
For organisations seeking a comprehensive overview of authentication options, Thales offers an extensive portfolio of MFA tokens and authenticators. Our OneWelcome Authenticators Portfolio includes FIDO2 passkeys, hardware tokens, smart cards, and software authenticators, ensuring secure access across different environments and devices . This breadth of choice allows organisations to select the authentication method best suited to their security requirements and user needs
When setting up MFA, you have several authentication options:
Authenticator App (recommended): Generates a new 6-digit code every 30 seconds. This method is very secure, works offline, and is significantly more phishing-resistant. Pros: High security, no network dependency. Cons: Requires your phone.
Text Message (SMS): Sends a one-time code to your mobile phone. Pros: Easy to use, no app required. Cons: Slightly less secure than authenticator apps due to potential SIM-swapping attacks, but still greatly improves security over no MFA. CISA recommends SMS-based authentication only as a “last resort” when more secure options aren’t available
Email Codes: Sends verification codes to your registered email. Pros: No extra device needed. Cons: Least secure option if your email is compromised. Use only if other methods aren’t feasible, and ensure your email itself has MFA.
Hardware Security Keys: Physical devices, such as Thales FIDO Security Keys that you plug in or tap to verify login. Pros: Highest level of security, phishing-resistant. Cons: Requires purchasing a device.
Which should you choose? If possible, use an authenticator app or hardware key, as these are most secure. For most users, an authenticator app strikes an excellent balance. SMS is a solid fallback, and email can work if necessary – just be aware of the security trade-offs.
Moving Beyond Passwords: Passwordless Authentication
Whilst MFA significantly strengthens security, the most forward-thinking organisations are taking the next step: eliminating passwords altogether. Passwordless authentication removes the vulnerabilities inherent in password-based systems – no passwords to steal, phish, or reuse.
Thales’ SafeNet Trusted Access empowers organisations to build comprehensive passwordless policies using FIDO2 passkeys, biometrics, and hardware authenticators. Our Passwordless 360 approach provides a detailed framework for implementing passwordless authentication across your organisation, combining security, user experience, and regulatory compliance.
Q: Do I have to enter an MFA code every single time I log in?
A: Often not every time. Many systems offer the option to “remember” a device for a certain period (e.g., 14 days). This means you won’t need to enter a code each time on that trusted device. However, use this feature only on personal devices you control, not shared or public computers.
Q: I’m not receiving the MFA code, or it says the code is wrong. What should I do?
A: Common solutions include: For SMS, check your signal and that your phone number is correct in account settings. Wait a moment and click “Resend code” if available. For authenticator apps, ensure your phone’s clock is accurate, as codes are time-based. For email, check your spam folder.
Q: What if I lose access to my phone or MFA device?
A: Use your saved backup codes to log in. If you’ve lost those as well, contact Thales support for account recovery assistance.
Q: Can we use our own IdP?
A: Yes, you can leverage external IdPs like SafeNet Trusted Access by Thales, which allows you to build adaptive authentication policies and leverage a broad range of MFA options.
Q: Can I switch MFA methods?
A: Yes. You can disable MFA and re-enable it with a new method anytime through your account settings.
Q: Is MFA required?
A: Whilst not mandatory on all accounts today, we strongly recommend enabling it. It’s one of the most effective ways to protect your account.
Thales’ research demonstrates the critical importance of strong identity and access management. Our 2025 Digital Trust Index – Third-Party Edition reveals that 96% of third-party users face issues logging into partner systems, wasting 48 minutes a month on average. Additionally, 40% reset passwords once or twice a month – highlighting the need for more secure, passwordless methods like MFA.
The 2025 Data Threat Report further emphasises this urgency. According to our research, 83% of organisations report that strong MFA is used more than 40% of the time, yet challenges remain. As organisations adopt AI and face evolving quantum threats, robust authentication becomes even more critical.
Thales’ comprehensive Identity and Access Management solutions provide organisations with the capabilities needed to improve user experiences whilst strengthening security. From Multi-Factor Authentication and Single Sign-On to passwordless authentication and passkeys, Thales delivers the tools to make IAM processes straightforward and dependable.
Cybersecurity is a shared responsibility. We design secure systems, and you make them stronger by turning on protections like MFA. Enable MFA today in your Thales account settings. It takes just a few minutes and makes a significant difference.
Secure by design starts with secure choices.
The post Security by Design: Why Multi-Factor Authentication Matters More Than Ever appeared first on Blog.


The surge in AI-driven traffic is transforming how websites manage their content. With AI bots and agents visiting sites at unprecedented rates (often scraping without permission, payment, or attribution) content owners face a critical challenge: how to protect their intellectual property while capitalizing on legitimate AI use cases.
Today, we’re excited to announce Imperva’s integration with TollBit, a groundbreaking solution that enables our Cloud Web Application Firewall (CWAF) customers to monetize traffic from AI bots and crawlers that would otherwise scrape their content without permission or compensation.
The traditional ad-supported and subscription-based content models are being disrupted by AI. This integration provides a new economic model where value flows fairly between content creators and AI developers, transforming unauthorized scraping into a sustainable revenue stream.
The integration leverages Imperva’s industry-leading Web Application Firewall capabilities alongside TollBit’s analytics and monetization platform to create a comprehensive solution:
The integration requires a straightforward setup process:
To ensure compatibility with TollBit’s requirements, an AWS Lambda function prefixes dates to Imperva log file names, enabling seamless ingestion into TollBit’s analytics platform.
This partnership represents a fundamental shift in how content owners approach AI traffic. Rather than simply blocking all bots or allowing unrestricted scraping, sites now have granular control to enforce access rules and pricing on their own terms.
Content owners deserve fair compensation for how their content powers the AI ecosystem. By combining Imperva’s security capabilities with TollBit’s monetization tools, we’re enabling the transition from unauthorized scraping to sustainable, licensed transactions.
With this integration, Imperva CWAF customers gain:
The agent economy is here, and autonomous AI visitors are becoming a permanent fixture of web traffic. With Imperva and TollBit, you can ensure these interactions happen on your terms—fairly, transparently, and profitably.
If you’re an Imperva Cloud WAF customer and want to activate the integration:
TollBit is free for publishers and websites so you can be up and running in no time.
The post Imperva Partners with TollBit to Power AI Traffic Monetization for Content Owners appeared first on Blog.


The more critical APIs become, the more sensitive data they carry identities, payment details, health records, customer preferences, tokens, keys, and more.
And this is where organizations face a painful, often invisible problem:
Most API security tools still rely on raw-payload logging, traffic replay, or shipping full request bodies into external analytics systems. That means sensitive customer data:
This creates a direct conflict between security, privacy, and compliance, and businesses are caught in the middle.
Across industries – financial services, retail, healthcare, travel, public sector, the story repeats:
1. Breach blast radius expands
The more systems that hold raw API payloads, the bigger the impact when any one of them is compromised.
2. Compliance becomes harder, not easier
GDPR, CCPA, HIPAA, PCI, and emerging data-sovereignty regulations penalize:
Most API security tools inadvertently violate all four.
3. Data residency rules block API security deployments
Organizations operating in multiple regions can’t centralize raw API data in a single cloud service, but many tools require doing exactly that.
4. Dev and QA environments become privacy risks
When security tests are based on production payload replays, sensitive data leaks into non-production systems.
5. Security teams lose visibility if they avoid raw logging
Many leaders try to “lock down” data flows, but that often leaves API blind spots, making it harder to detect business logic abuse, scraping, or session-based attacks.
This is the API privacy paradox:
You either weaken privacy to strengthen security or weaken security to preserve privacy.
The traditional API security model makes three flawed assumptions:
These assumptions create privacy exposure, compliance failure, and operational friction.
Imperva Solves This by Rethinking the Architecture
Imperva’s privacy-first, local-first platform was built around a core belief:
API security should not require exposing sensitive data, ever.
The architecture flips the traditional model:
1. Inspect at the PoP (where traffic lives)
Traffic is parsed in-memory at the Point-of-Presence closest to the application, SaaS PoP or on-prem.
Raw values never leave the PoP.
2. Convert sensitive values into privacy-safe artifacts
Classification + hashing replaces raw payloads with:
3. Detect and respond using metadata only
Anomaly detection uses metadata such as:
No raw content is needed or exposed.
4. Enforce using hashes, not identities
Hash-based enforcement enables:
5. Same privacy guarantees across all deployments
Cloud, on-prem, hybrid – the mechanics never change.
This is where Imperva’s architecture translates directly into measurable, enterprise-wide value:
Smaller blast radius = lower breach liability
Fewer systems hold PII, drastically reducing what attackers can steal and what you must disclose.
Faster compliance alignment
Local data processing and zero raw persistence align with GDPR, HIPAA minimum-necessary, and sovereignty rules.
Real-time protection with zero added exposure
Inline, in-PoP inspection gives detection teams full visibility without raw payload retention.
Safer automation in Dev/QA
Privacy-aware test artifacts eliminate the risk of production PII leaking into pipelines.
Reduced third-party risk
Vendors never receive raw payloads, only metadata and hashes.
A future-proof privacy posture
As regulatory pressure increases, architectures like this become mandatory, not optional.
This whitepaper breaks down exactly how Imperva delivers production-grade API protection while preserving privacy, with clear explanations and practical examples.
You’ll learn:
In other words:
If you need to secure APIs and meet privacy, residency, or compliance requirements – this is essential reading.
Download the whitepaper and learn how Imperva protects APIs without exposing sensitive data.
The post The Privacy Gap in API Security: Why Protecting APIs Shouldn’t Put Your Data at Risk appeared first on Blog.


The holiday shopping season is the busiest time of year for online retailers, and increasingly the most dangerous. As traffic surges and customers rush to place orders, cybercriminals use the distraction and volume to blend in. Account Takeover (ATO) attacks spike sharply in November and December, targeting shoppers’ saved payment details, loyalty points, wish-lists, and personal data.
Most retailers focus on keeping sites fast and campaigns running smoothly, but this seasonal pressure creates blind spots in authentication, login flows, and Application Programming Interface API endpoints. Attackers know this and use automated tools and AI-driven bots to slip into accounts with little resistance.
During peak season, it doesn’t take long for an unnoticed credential-stuffing surge, or a burst of suspicious login attempts to translate into real financial loss and customer frustration. For many retailers, the challenge isn’t a dramatic breach, it’s the quiet, persistent account abuse that goes undetected until the damage is already done.
According to the 2025 Imperva Bad Bot Report, Account Takeover attacks increased by 40 percent in 2024 and by more than 50 percent since 2022. The rise reflects the expanding attack surface of modern digital businesses and the increasing availability of stolen credentials.
ATO attacks are rarely brute force assaults in the traditional sense. Most rely on automation and intelligence. Attackers use:
Each of these techniques is enhanced by bot networks capable of emulating legitimate traffic and distributing attacks across thousands of IP addresses to avoid detection.
Once an account is compromised, attackers can alter stored payment details, redeem loyalty points, exfiltrate personal data, or pivot into connected systems through single sign on integrations. The damage can be widespread and difficult to undo, making remediation costly, complex, and often too late to fully protect the victim.
A successful Account Takeover is not just a security failure; it is a business crisis. The consequences cascade across financial, regulatory, and reputational dimensions.
Regulators increasingly view inadequate protection of user credentials as a preventable failure. In industries such as financial services, retail, and telecom, where digital identity underpins customer engagement, the stakes are exceptionally high.
Artificial intelligence is amplifying both the scale and sophistication of ATO campaigns. Where brute force once relied purely on volume, AI brings adaptive learning and behavioural mimicry.
Modern credential stuffing bots now simulate human navigation, introduce artificial pauses, and mirror typing patterns to bypass rate limits and behavioural detection systems. Machine learning
models trained on breached data can predict likely password sequences based on language, demographics, and prior password resets.
This capability turns traditional defences into speed bumps rather than barriers. The result is faster, more evasive attacks that require intelligent, context aware countermeasures.
As organizations modernize applications, APIs have become both essential and exposed. They connect services, mobile clients, and third-party integrations, and they now represent a primary conduit for identity and data access.
According to Imperva telemetry, around 12 percent of all API attacks in 2024 were Account Takeovers. Many of these attacks are low volume and high value, designed to evade detection. Attackers harvest sensitive information in small increments such as user identifiers, loyalty balances, and payment tokens, and use that data later for large scale fraud or identity theft.
During the holiday shopping season, attackers take advantage of the fact that retail systems are under more pressure and handling far more automated traffic than usual. Bots are designed to blend seamlessly into this activity. They mimic real customers using legitimate browsers, realistic headers, and correctly formatted API calls, which makes them difficult to distinguish from genuine shoppers.
Instead of triggering obvious high-volume spikes, attackers quietly test stolen credentials across login APIs, probe authentication flows, and map out which accounts are valid. They reuse tokens, exploit weak session handling, and launch credential stuffing campaigns at a pace that fits naturally within peak season traffic. Because the requests look structurally correct, they often bypass volumetric detection and slip past basic rate limits.
Once inside an account, automated scripts extract loyalty balances, change delivery addresses, modify stored payment methods, or pivot through single sign on to gain access to additional services. For many retailers, these subtle API driven attacks are now the fastest growing source of credential-based compromise, and they reach their highest risk in November and December.
1. Improve visibility across login traffic this holiday season
During peak shopping periods, login volumes surge and attackers use the noise to hide. Monitor login attempts, unusual session behaviour, device changes, and repeated failures so you can spot suspicious activity early.
2. Strengthen authentication without slowing real customers
Shoppers expect fast checkout experiences, especially during sales events. Use smarter authentication controls that react to risk signals such as new devices or sudden spikes in login attempts, while keeping the journey seamless for genuine users.
3. Protect high value pages such as login and checkout
These are the most heavily targeted points during the holiday rush. Account Takeover attacks often begin on the login page and escalate at checkout. Ensure these flows have the strongest monitoring and protection in place to detect unusual behaviour before accounts are compromised.
4. Secure all APIs involved in customer accounts and orders
Retailers rely on APIs for login, checkout, loyalty, order history, and account management. These endpoints see huge traffic increases in November and December, making them prime targets for automated abuse. Apply full visibility and security controls across them.
5. Deploy Advanced Bot Protection to stop automated ATO attempts
Bots spike dramatically during holiday promotions. Advanced bot protection identifies and blocks automated credential testing, scripted login attempts, and account probing in real time without adding friction for real shoppers. This is critical for preventing ATO during your busiest weeks.
Visit Imperva.com Account Takeover Protection.
The post ’Tis the Season to Be Cyber-Wary: How Thales Protects Against Account Takeover During Peak Shopping Season appeared first on Blog.
