Is there a CVE ID for the Snowflake GitHub Actions vulnerability?

No CVE was assigned. Wiz reported the script injection flaw through Snowflake's HackerOne vulnerability disclosure program as report #3819931, and Snowflake patched it the same day.

How did GitHub Copilot Autofix introduce the vulnerability?

Commit 4a1b8ce in PR #1218 removed the repository's safe pattern, which passed the GitHub issue title through an env: variable and built the JSON payload with jq --arg. Copilot Autofix replaced it with direct string expansion of the issue title inside a shell command, creating a script injection vector.

Was Snowflake customer data affected?

No. The exfiltrated token gave read access to Snowflake's internal Jira projects covering engineering, security compliance and bug bounty tracking. Snowflake's audit log analysis found no evidence of unauthorised access, with all anomalous queries matched to Wiz's testing IPs.

How do I check if my GitHub Actions workflows are vulnerable?

Look for workflows triggered by issues, issue_comment, pull_request_target or discussion events that interpolate ${{ github.event.* }} expressions directly into run: blocks. The open-source auditor zizmor flags this pattern under its template-injection rule.

Which SCCM versions are affected by CVE-2026-47301?

Microsoft Configuration Manager current branch versions 2503 (with update rollup KB32851084 installed), 2509, and 2603.

How long until my Blogger blog comes back?

There is no guarantee. Observed restorations during the August 2026 incident ran roughly 6 to 20 hours from the time of the lock. Google's official policy allows appeals to take up to 10 business days.

Will I lose my Blogger content permanently?

Not if you act. The Blogger lock screen states that a removed blog is permanently deleted within 89 days. Export your content through Google Takeout well before that deadline.

How can I check whether my blog really has malware?

Check Google Search Console under Security Issues, review the Google Safe Browsing Transparency Report, and scan your domain through VirusTotal. Essentially every affected user who ran these checks during the August 2026 incident found all three clean.

Can I export my blog with Google Takeout while it is locked?

Sometimes. Reports conflict: several users successfully exported locked blogs, while others found their posts missing from the archive. Request the export immediately, then request it again once your blog is restored, and verify the second archive actually contains your posts.

Should I delete my Blogger blog and start over?

No. Deleting the blog forfeits both your pending appeal and the 89-day window before permanent deletion.

Does a Blogger lock affect AdSense earnings?

Yes. While the blog is locked it serves no ads and earns nothing. Several users also reported pending AdSense applications caught mid-review when their blog was removed.

What is the feed.atom file in a Google Takeout backup?

feed.atom contains every post, page and comment from your blog, including drafts. It replaced Blogger's old one-click XML export in July 2025. Importantly, it does not contain your images; it stores only the markup that renders them from Google's servers.

Why does my restored Blogger blog keep getting locked again?

Reports from the August 2026 incident consistently link re-locks to template and layout writes rather than post edits. Editing theme HTML, changing gadgets, importing a theme, or inserting and removing ad code all preceded second locks. Editing posts and pages generally did not. Freeze your template until Google confirms a fix.

Cyber Kendra

Apple Patches 122 Flaws including macOS Screen Sharing Flaw (CVE-2026-65400)

protalweb@gmail.com (Vivek Gurung) — Tue, 18 Aug 2026 08:24:26 +0530

Apple shipped four security updates on August 17, 2026, fixing 122 vulnerabilities in iOS 18.7.10 and iPadOS 18.7.10, 29 in iOS 26.6.1 and iPadOS 26.6.1, and 28 in macOS Tahoe 26.6.2. None of the flaws in this batch are known to have been exploited — but a separate macOS bug Apple patched eleven days earlier is being used right now to plant cryptominers on internet-facing Macs.

The standout new issue is CVE-2026-65329, a Telephony flaw that only affects iPhone 11 and later. Apple describes it as an authentication issue that lets an attacker in a privileged network position bypass IPSec authentication and intercept network traffic, and credits Bedran Karakoc, Tobias Funke, Jacopo Clark and Katharina Kohls of Ruhr University Bochum. It is the single vulnerability that separates iOS 26.6.1 from macOS Tahoe 26.6.2 — the other 28 fixes are identical across both.

What Apple Released on August 17, 2026

Apple published three security advisories and shipped a fourth update with no advisory attached. As of August 18, 2026, visionOS 26.6.1 is listed on Apple's security releases page with the note that details are coming soon.

Update	Devices covered	CVEs fixed
iOS 26.6.1 and iPadOS 26.6.1	iPhone 11 and later, iPad Pro 12.9-inch 3rd generation and later, iPad Pro 11-inch 1st generation and later, iPad Air 3rd generation and later, iPad 8th generation and later, iPad mini 5th generation and later	29
iOS 18.7.10 and iPadOS 18.7.10	iPhone XS, iPhone XS Max, iPhone XR, iPad 7th generation	122
macOS Tahoe 26.6.2	macOS Tahoe	28
visionOS 26.6.1	Apple Vision Pro	Not yet published

There is no watchOS, tvOS, Safari or Xcode update in this round. macOS Sequoia and macOS Sonoma also sat this one out — those branches last received fixes on August 6, 2026, in macOS Sequoia 15.7.9 and macOS Sonoma 14.8.9.

Are Any of These Vulnerabilities Being Exploited?

No. Apple's advisories for iOS 26.6.1, iOS 18.7.10 and macOS Tahoe 26.6.2 contain none of the language Apple normally uses when a flaw has been attacked in the wild, and no CVE in the August 17 batch carries an exploitation note. There are no zero-days here.

That is not the same as saying Apple users are safe this week. A macOS flaw Apple patched on August 6, 2026 — CVE-2026-65400 in Screen Sharing — is under active exploitation, and it is the bug Mac administrators should be chasing today.

CVE-2026-65400: The Screen Sharing Flaw That Is Actually Being Attacked

CVE-2026-65400 is an authentication bypass in screensharingd, the daemon behind macOS Screen Sharing, which exposes remote desktop access over the VNC protocol on TCP port 5900. Apple fixed it on August 6, 2026, in macOS Tahoe 26.6.1, macOS Sequoia 15.7.9 and macOS Sonoma 14.8.9, crediting Alfredo Pesoli (@__rev) via Bynario Atlas.

The Netherlands' National Cyber Security Centre (NCSC-NL) updated its advisory NCSC-2026-0280 on August 12, 2026, to report active exploitation. According to NCSC-NL, attackers hit multiple systems with port 5900 reachable from the internet, and in every confirmed case, "root had been accessed on the affected system" before a Monero cryptocurrency miner was installed.

Because the bypass happens before authentication, the hardening steps most Mac administrators would reach for do not help. Removing approved Screen Sharing users, disabling legacy VNC password access and rotating the VNC password all sit downstream of the check the flaw defeats. Security firm Calif, which analysed the bug, noted that the attack needs only a valid account name, and that "a username is not a secret" on macOS.

How the assessment of CVE-2026-65400 changed over 12 days

The public record on this vulnerability moved faster than most tracking systems did, and the sources still disagree. Cyber Kendra assembled the following timeline from Apple's advisory, the NVD change log and NCSC-NL's advisory.

Date	Source	Assessment
6 Aug 2026	Apple advisory HT148170	Patch shipped, no exploitation noted
7 Aug 2026	NVD (CISA-ADP)	CVSS 3.1 scored 7.1 High, CWE-287, impact partial
7 Aug 2026	NCSC-NL advisory NCSC-2026-0280	Advisory published, no exploitation reported
12 Aug 2026	NCSC-NL advisory update	Active exploitation observed, root access and Monero miner
14 Aug 2026	NVD (CISA-ADP)	CVSS 3.1 raised to 9.8 Critical, attack rated automatable
15 Aug 2026	CISA SSVC record	The exploitation decision point is still recorded as "none"
18 Aug 2026	CISA KEV catalog	Not listed at time of writing

The gap matters operationally. A team that filters patch priority on CISA KEV membership alone would not have flagged CVE-2026-65400 as of August 18, 2026, even though a European national CERT has documented root compromise in the wild and the CVSS vector was rewritten to reflect no privileges required and full compromise of confidentiality, integrity and availability.

Cyber Kendra has not independently verified the exploitation reports and is relying on NCSC-NL's published advisory.

If you cannot patch immediately, disable Screen Sharing in System Settings under General, then Sharing, and block TCP port 5900 at the network edge. CVE-2026-65400 is also distinct from CVE-2026-43760, a separate Screen Sharing issue that requires the attacker to already know a configured VNC password.

What iOS 26.6.1 and macOS Tahoe 26.6.2 Actually Fix

iOS 26.6.1 and macOS Tahoe 26.6.2 patch the same 28 vulnerabilities, with the iPhone-only Telephony flaw making up iOS's 29th. Both updates are unusually browser-heavy: 21 of the 29 CVEs in iOS 26.6.1 sit in WebKit, WebKit History or WebKit Storage.

The fixes worth knowing about outside WebKit:

CVE-2026-65346 (ImageIO) — an integer overflow where processing an image may lead to arbitrary code execution. Credited to Meta Red Team X's Nik Tsytsarkin.
CVE-2026-65339 (Audio) — a logic issue that could let an app leak sensitive user information. Also credited to Meta Red Team X.
CVE-2026-65343 (Kernel) — a use-after-free that a remote attacker could use to cause unexpected system termination.
CVE-2026-65330 and CVE-2026-65349 (Kernel) — memory corruption and out-of-bounds read issues reachable from an app.
CVE-2026-64788 (IOGPUFamily) — memory corruption triggered by maliciously crafted web content, which pairs a browser entry point with a graphics driver bug.
CVE-2026-65347 (ImageIO) — a denial-of-service when processing an image.

Apple does not publish CVSS scores in its advisories, so severity ratings for these CVEs will only appear once NVD analysts enrich them.

Why iOS 18.7.10 Fixes 122 Bugs When iOS 26.6.1 Fixes Only 29

The 122 figure is the headline number this round, and it is widely misread. iOS 18.7.10 is not a bigger or more urgent update than iOS 26.6.1 — it is a backport that closes a two-release backlog for legacy hardware in one go.

Apple states in the advisory that iOS 18.7.10 delivers fixes first made available in the iOS 26.6 and 27 betas. iOS 26.6 shipped to modern devices on July 27, 2026, and iOS 26.6.1 shipped on August 17. Devices still on the iOS 18 branch missed both, so Apple rolled roughly six weeks of accumulated fixes into a single release.

iOS 18.7.10 also covers a much smaller device set than earlier iOS 18.7.x releases did: only iPhone XS, iPhone XS Max, iPhone XR and the 7th-generation iPad. As recently as iOS 18.7.8 in April 2026, that branch still served iPhones through the iPhone 16 range.

Here is where the 122 CVEs land by component:

Component	CVEs in iOS 18.7.10
WebKit (including Canvas, History, Process Model, Storage)	42
Kernel	18
Model I/O	9
ImageIO	5
SceneKit	4
WebRTC	3
CoreAudio	3
Contacts	3
All other components	35

Forty-five of the 122 CVEs — WebKit plus WebRTC — are browser-engine bugs. That is the reachable-from-a-web-page attack surface, and it is why an old iPhone left unpatched is a meaningfully worse place to browse the web than a current one.

AI Tooling Now Accounts for a Third of Apple's WebKit Credits

The most durable story in this release is not a single CVE. It is who found the bugs. Nine of the 29 CVEs in iOS 26.6.1 are credited to OpenAI Codex Security, all to researcher Amy Burnett, and the same nine appear in macOS Tahoe 26.6.2.

Widen the view to iOS 18.7.10, which carries the full two-release backlog, and the pattern becomes clearer. Cyber Kendra counted the AI-lab and AI-tooling credits across all 122 entries:

Credited to	CVEs in iOS 18.7.10	Example
OpenAI Codex Security — Amy Burnett	10	CVE-2026-65331
Milad Nasr and Nicholas Carlini with Claude, Anthropic	1	CVE-2026-64757
Trail of Bits via Anthropic CVD	1	CVE-2026-28984
Z.AI GLM	1	CVE-2026-43663
NVIDIA AI Red Team — Aaron Grattafiori	1	CVE-2026-43701

That is 14 CVEs, all of them in the WebKit family, out of 45 browser-engine bugs in the release — roughly 31 percent. Some of those credits are shared with human researchers, so the correct reading is that AI-assisted review contributed to about a third of Apple's browser-engine findings this cycle, not that it found them alone.

We would treat this as the leading indicator to watch across Apple's next few releases. WebKit is a large, fuzzable, memory-unsafe C++ codebase with a clear crash oracle, which makes it close to a best case for automated bug discovery. If the share holds or grows in iOS 27, the volume of WebKit CVEs per release is likely to keep climbing — and a rising CVE count will say more about detection capacity than about code quality getting worse.

Apple Confirms macOS 27 Is Called Golden Gate

Apple's own advisory text for macOS Tahoe 26.6.2 says the update delivers "security fixes that were first made available in the macOS Golden Gate 27 beta". The iOS 26.6.1 advisory makes the matching reference to the iOS 27 and iPadOS 27 betas.

That is Apple naming its next macOS release in a support document rather than at an event. Following Sequoia, Sonoma and Tahoe, Golden Gate continues Apple's California landmark naming convention. Apple has not published a release date for macOS 27 or iOS 27.

Which Update Should You Install?

Your device will only offer the one build that applies to it. There is no choice to make and no reason to delay.

iPhone 11 or newer — install iOS 26.6.1.
iPhone XS, XS Max or XR — install iOS 18.7.10. These devices cannot run iOS 26.
iPad 7th generation — install iPadOS 18.7.10. All newer iPads get iPadOS 26.6.1.
Mac on macOS Tahoe — install macOS Tahoe 26.6.2.
Mac on macOS Sequoia or Sonoma — you are on 15.7.9 or 14.8.9 from August 6. Confirm you took that update, because it carries the CVE-2026-65400 Screen Sharing fix.
Apple Vision Pro — install visionOS 26.6.1.

How to install

On iPhone or iPad, open Settings, tap General, then Software Update.
On Mac, open System Settings, click General, then Software Update.
On Apple Vision Pro, open Settings, tap General, then Software Update.
Turn on Automatic Updates on the same screen so future security fixes install without you checking.

Note that iOS, iPadOS, tvOS, watchOS and visionOS cannot be downgraded once a software update is installed.

Frequently Asked Questions

Is there a zero-day in the August 17, 2026 Apple updates?

No. Apple's advisories for iOS 26.6.1, iOS 18.7.10 and macOS Tahoe 26.6.2 do not mark any CVE as exploited in the wild, and none of the 122, 29 or 28 fixes carries an exploitation note.

What is CVE-2026-65400 and am I affected?

CVE-2026-65400 is an authentication bypass in macOS Screen Sharing that lets a network attacker connect without valid credentials. You are affected if you run macOS Sonoma before 14.8.9, macOS Sequoia before 15.7.9 or macOS Tahoe before 26.6.1 with Screen Sharing enabled. NCSC-NL reported active exploitation against Macs exposing TCP port 5900 to the internet.

Why does iOS 18.7.10 fix 122 vulnerabilities?

iOS 18.7.10 backports fixes that Apple first shipped in the iOS 26.6 and 27 betas. Devices on the iOS 18 branch missed both the July 27 and August 17 releases, so Apple bundled roughly six weeks of accumulated fixes into one update.

Do I need to update if I never use Screen Sharing?

Yes. Screen Sharing is only one of the issues fixed this month, and the August 17 updates patch kernel, ImageIO, Audio and WebKit flaws that are reachable without it. Disabling Screen Sharing is a stopgap for unpatched Macs, not a substitute for updating.

Which Apple devices are no longer getting security updates?

Apple still ships fixes to the iOS 18, iOS 16 and iOS 15 branches for older hardware, though coverage narrows with each release. iOS 18.7.10 now covers only iPhone XS, iPhone XS Max, iPhone XR and the 7th-generation iPad.

What does visionOS 26.6.1 fix?

Apple has not published the security content for visionOS 26.6.1. As of August 18, 2026 the release is listed on Apple's security releases page with details marked as coming soon.

Amazon Scans and Destroys Rare Books for AI Training - Report

protalweb@gmail.com (Vivek Gurung) — Tue, 18 Aug 2026 08:49:06 +0530

Amazon is buying printed books in bulk, cutting the bindings off, scanning the pages for AI training data and discarding the paper, according to a 404 Media investigation published on 17 August 2026. Reporter Emanuel Maiberg confirmed the operation by hiding an Apple AirTag inside one book in a 1,000-title order and tracking it across the United States.

The tracker's final stop was LAS8, an Amazon warehouse in north-east Las Vegas, Nevada. The book-scanning unit inside LAS8 is called VGT3, and the logo at its entrance is a Tyrannosaurus rex holding an open book.

What the AirTag Investigation Found

The 1,000-book order was placed through Biblio, a rare and used book marketplace that keeps buyer identities anonymous. An anonymous bookseller working with 404 Media planted the AirTag, which moved through several states before arriving in Las Vegas.

Amazon employees describing VGT3 on worker forums said their entire job is receiving pallets of books, scanning barcodes and cutting bindings so the pages feed through scanners faster. Amazon told 404 Media it "purchases books through commercial channels" to improve its products, and named no model. Secondary coverage of the investigation has tied the data to Amazon's Nova model family; Amazon has not confirmed that.

Why AI Companies Want Printed Books

Printed text published before 2022 is the scarcest training resource in AI right now. Much of it was never digitised, so it escaped the web scrapes every large model has already consumed — and nothing printed before 2022 can contain AI-generated text. That second point matters because training a model on other models' output degrades it, a failure researchers call model collapse.

Booksellers told 404 Media the buyers scan every ISBN (the serial number unique to each edition), which supports their theory that AI firms are working through printed books by serial number.

How Amazon Compares With Anthropic's Project Panama

Amazon is not the first company to do this. Court exhibits in Bartz v Anthropic PBC described an internal effort to "destructively scan all the books in the world", codenamed Project Panama. Judge William Alsup ruled that scanning lawfully purchased books to train a model was transformative fair use, partly because the printed original was destroyed rather than resold.

Detail	Amazon (VGT3)	Anthropic (Project Panama)
Revealed by	404 Media AirTag investigation, 17 Aug 2026	Court exhibits, Bartz v Anthropic PBC
Site	LAS8 warehouse, Las Vegas, Nevada	Third-party digitisation vendors
Method	Bindings cut, pages scanned, originals discarded	Spines cut, pages trimmed, originals discarded
Legal status	No court ruling as of 18 August 2026	Ruled transformative fair use by Judge Alsup

What This Means in India

No Indian court has ruled on destructive scanning. On 24 July 2026, Justice Amit Bansal of the Delhi High Court refused ANI Media an interim injunction against OpenAI, holding on a prima facie basis that storing news content to train a large language model falls under the fair dealing exception in Section 52(1)(a) of the Copyright Act, 1957. India's exceptions are a closed statutory list rather than the flexible US fair use test, and the physical destruction of a copy was never at issue there. The main ANI suit continues.

Quick Answers

Which Amazon facility scans books for AI training?

LAS8, an Amazon warehouse in north-east Las Vegas, Nevada. The scanning unit inside it is called VGT3.

Does Amazon destroy the books it scans?

Yes. Workers at VGT3 told 404 Media the bindings are cut off to speed up scanning, which destroys the printed copy.

Is destructive book scanning legal in India?

No Indian court has ruled on it as of 18 August 2026. The Delhi High Court's July 2026 interim order covered AI training on text, not the destruction of physical books.

The bookseller who worked with 404 Media put the objection plainly: "They just want the content as a bunch of words strung together."

The Role of an SEO Agency in Long-Term Organic Growth

protalweb@gmail.com (Vivek Gurung) — Tue, 18 Aug 2026 07:55:42 +0530

Organic growth rarely happens by accident. A website may publish useful content, attract a few backlinks, and rank for several keywords, but maintaining consistent visibility in search requires a structured, long-term strategy. This is where an SEO agency can make a significant difference.

Unlike short-term marketing tactics that focus on immediate traffic or conversions, search engine optimization is designed to build a sustainable digital presence. A professional team can combine technical optimization, content strategy, keyword research, authority building, and performance analysis to help a business compete consistently in organic search.

Why Long-Term SEO Matters

Search engines continually evolve, and user behavior changes alongside them. Businesses that rely on outdated optimization techniques can gradually lose rankings and organic traffic. Long-term SEO focuses on creating a website that remains useful to both search engines and users as these changes occur.

A sustainable strategy typically involves improving website architecture, creating valuable content, targeting relevant search intent, strengthening authority, and monitoring performance over time. These activities compound. A well-optimized article can continue attracting visitors months or even years after publication, while improvements to site structure can benefit multiple pages simultaneously.

This makes SEO different from many paid advertising campaigns. When an advertising budget stops, the traffic generated through those campaigns can decline immediately. Organic visibility, when built correctly, can continue generating qualified visitors without paying for every click.

What an SEO Agency Actually Does

An experienced SEO agency does more than add keywords to web pages. Its role is to identify opportunities, solve technical problems, improve content quality, and develop a strategy aligned with business objectives.

Common SEO agency services include:

Technical SEO audits and optimization
Keyword and search-intent research
On-page SEO
Content strategy and optimization
Internal linking
Website structure improvements
Local SEO
Link-building and digital PR
Competitor analysis
SEO performance tracking
Conversion-focused optimization

The exact combination depends on the website, industry, competition, and business goals. An eCommerce store, for example, may require extensive product-page optimization and technical work, while a B2B company may benefit more from topic clusters, thought leadership content, and authority building.

Building a Strong Technical Foundation

Technical SEO provides the foundation for sustainable organic performance. Search engines need to be able to discover, crawl, understand, and index a website efficiently.

A professional SEO team may analyze factors such as site architecture, crawlability, indexing, redirects, canonicalization, structured data, mobile usability, page experience, and website speed.

Technical improvements are particularly valuable because they can affect an entire website rather than just one page. Fixing duplicate content or improving internal linking, for example, can help search engines understand the relationship between important pages.

The best digital marketing company can also monitor technical issues continuously. This matters because websites are rarely static. New pages are added, old pages are removed, platforms change, and developers make updates that can unintentionally affect organic visibility.

Creating Content Around Search Intent

Content is another major component of long-term SEO. However, simply publishing large quantities of articles does not guarantee results.

Modern SEO requires understanding why someone performs a search and what information they expect to find. An effective content strategy, therefore, considers informational, commercial, navigational, and transactional search intent.

A strong SEO strategy may organize related topics into content clusters. A central page can cover a broad subject while supporting articles answer more specific questions. Internal links then connect these resources, helping users navigate the site while providing search engines with additional context.

This approach also allows businesses to demonstrate depth within their areas of expertise. Instead of chasing disconnected keywords, they can build a comprehensive resource around topics that matter to their audience

Developing Authority and Trust

High-quality content needs visibility and credibility. Authority building helps establish a website as a reliable resource within its industry.

An SEO team may support this through relevant backlinks, digital PR, expert contributions, partnerships, original research, and other legitimate forms of online promotion. The goal should not be to acquire as many links as possible, but to earn relevant mentions from trustworthy sources.

This is another reason businesses often work with a professional SEO agency. Sustainable link acquisition requires research, relationship building, content development, and careful evaluation of opportunities. Poor-quality or manipulative tactics can create unnecessary risks rather than sustainable growth.

Measuring SEO Beyond Rankings

Rankings remain useful, but they should not be the only measure of SEO success.

A comprehensive SEO measurement framework can examine organic traffic, impressions, click-through rates, conversions, qualified leads, revenue, engagement, and the performance of individual landing pages. Businesses can then identify which activities contribute to meaningful commercial outcomes.

For example, ranking first for a high-volume keyword may look impressive, but a lower-volume keyword that generates qualified leads could be more valuable. The best SEO agency for a business should therefore focus on business impact rather than vanity metrics alone.

Regular reporting also allows strategies to evolve. If a content category attracts traffic but produces few conversions, the team can investigate search intent, improve calls to action, or adjust the targeting strategy.

Adapting to Search in an AI-Driven Era

Search is becoming increasingly complex as AI-generated answers, conversational search experiences, and new discovery platforms influence how people find information.

This does not make traditional SEO irrelevant. Instead, it increases the importance of creating content that is genuinely useful, well-structured, authoritative, and easy for search systems to understand.

Businesses should focus on answering real customer questions, demonstrating expertise, maintaining accurate information, and building a strong overall digital presence. An SEO team can help monitor these developments and adjust the strategy as search experiences change.

The goal is not to optimize for a single feature or algorithm. It is to build a digital asset capable of attracting users through multiple organic discovery paths.

Choosing the Right SEO Partner

Not every provider approaches SEO in the same way. When comparing SEO company services, businesses should look beyond promises of instant rankings or guaranteed positions.

A reliable partner should explain its methodology clearly, establish measurable objectives, communicate regularly, and connect SEO activities to business outcomes. It should also be willing to prioritize sustainable improvements over shortcuts.

Businesses can evaluate potential partners by reviewing their experience, case studies, reporting processes, technical capabilities, content expertise, and understanding of the relevant industry.

The right partnership should feel less like outsourcing a checklist and more like working with an extension of the internal marketing team.

SEO Is an Investment, Not a One-Time Task

Long-term organic growth requires consistency. Search visibility can take time to develop, particularly in competitive industries, but the cumulative value can be substantial.

A business that continually improves its website, publishes useful resources, earns authority, fixes technical issues, and measures outcomes is building an organic marketing asset. Each improvement can support future performance.

That is the central role of an SEO agency: not simply to help a website rank for keywords, but to create a repeatable strategy for attracting relevant audiences through search.

When SEO is treated as an ongoing investment rather than a one-time project, businesses can build stronger visibility, more qualified traffic, and a foundation for sustainable digital growth.

FAQs

1. What does an SEO agency do?

An SEO agency improves a website’s visibility in search engines through technical SEO, keyword research, content optimization, link building, competitor analysis, and ongoing performance monitoring.

2. How long does SEO take to show results?

SEO typically takes several months to produce significant results. The timeline depends on factors such as website authority, competition, technical condition, content quality, and the SEO strategy being implemented.

3. Why should a business hire a professional SEO agency?

A professional SEO agency brings specialized expertise, tools, and experience to identify opportunities and technical issues that may be difficult to find internally. It can also provide a consistent long-term strategy.

4. What SEO services should an agency provide?

Common SEO services include technical SEO, keyword research, on-page optimization, content strategy, internal linking, local SEO, link building, competitor research, and performance reporting.

5. How do I choose the best SEO agency?

Look for an agency with a transparent process, relevant industry experience, measurable reporting, realistic expectations, and a focus on sustainable growth rather than guaranteed rankings or quick fixes.

Copilot Autofix Bug Exposed Snowflake's Internal Jira

protalweb@gmail.com (Vivek Gurung) — Mon, 17 Aug 2026 23:08:40 +0530

Wiz Research's autonomous "Red Agent" found and exploited a script injection flaw in Snowflake's public snowflake-connector-net repository, using nothing but a crafted GitHub issue title to steal credentials for Snowflake's internal Jira.

The vulnerability had been introduced five days earlier by GitHub Copilot Autofix — an AI tool built to fix security bugs.

No CVE ID has been assigned. Wiz reported the issue through Snowflake's HackerOne program as report #3819931. The bug sat in the jira_issue.yml workflow, which fired on issues: opened and interpolated the attacker-controlled title straight into a run: block — arbitrary command execution on the Actions runner for any unauthenticated GitHub user.

How an AI "Autofix" Created the Flaw

Commit 4a1b8ce (PR #1218), co-authored by Copilot Autofix powered by AI, deleted the repository's safe pattern — the issue title passed through an env: variable and built into JSON with jq --arg — and replaced it with direct string expansion:

- env:
-   ISSUE_TITLE: ${{ github.event.issue.title }}
- run: jq -n --arg title "$ISSUE_TITLE" ...
+ run: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...)

The sed escaping runs after GitHub expands the template, so a single quote in the title breaks out of echo '...'. Red Agent's first payload triggered a bash EOF error; the agent analysed the failure, rewrote the payload, and exfiltrated JIRA_API_TOKEN, JIRA_USER_EMAIL and JIRA_BASE_URL as base64 to an out-of-band listener.

Why the Workflow's Security Gate Did Nothing

The workflow's if: condition is compared github.event.pull_request.user.login against a bot account. In issues events that object is always null, reducing the check to null != 'whitesource-for-github-com[bot]' — permanently true. Every GitHub user passed the gate.

The stolen token was authenticated as qa@snowflake.net to snowflakecomputing.atlassian.net, granting read access to engineering, security compliance and bug bounty projects. Snowflake's audit logs matched every anomalous query to Wiz's testing IPs and found no evidence of unauthorised third-party access.

How to Check Your Own Workflows

Any workflow triggered by issues, issue_comment, pull_request_target or discussion that places ${{ github.event.* }} inside a run: block is exploitable the same way. The open-source Actions auditor zizmor flags this exact line under its template-injection rule. Pass untrusted input through env: variables, quote it as "$VAR", and treat AI-generated workflow commits as untrusted code requiring the same review as any external contribution.

GitHub Down as Outage Hits Actions, API and Copilot

protalweb@gmail.com (Vivek Gurung) — Mon, 17 Aug 2026 21:37:37 +0530

Status: MOSTLY RECOVERED — COPILOT STILL DOWN. At 16:59 UTC GitHub declared the degradation mitigated across API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks, and all seven are back to Operational. Copilot was not named in that update and is still marked as a Major Outage. The incident remains open while GitHub monitors for stability.

Last confirmed: 17 August 2026, 16:59 UTC (22:29 IST). This post is updated as GitHub posts new information.

Is it broken for you too? Report what's failing on our Downbits GitHub tracker — API, login, website or DNS. The more reports come in, the faster everyone else can tell whether it's GitHub or their own setup.

GitHub broke for developers worldwide for three hours and nineteen minutes, with roughly one in five requests to the website and the API returning errors, and about half of all archive downloads and raw repository content requests failing outright. The incident opened at 13:40 UTC (19:10 IST) on 17 August 2026 and widened steadily until GitHub declared seven of the eight affected services mitigated at 16:59 UTC. Copilot was not one of them.

The practical effect was larger than the error percentages suggest. A 50% failure rate on archive downloads and raw content means package installs that pull from GitHub, Docker builds that fetch files over raw github user content, and Go module downloads were all failing intermittently. Combined with a Major Outage on Actions, most CI/CD pipelines that touch GitHub in any way were unreliable for the entire affected window.

Is GitHub Down Right Now?

Not any more, with one exception. GitHub's own status page now shows every affected service back to Operational except Copilot, which is still marked as a Major Outage. Here is the component-by-component state as of the most recent check:

Service	Current state	90-day uptime
Copilot	Major Outage	99.84%
API Requests	Operational	99.82%
Issues	Operational	99.88%
Pull Requests	Operational	99.88%
Actions	Operational	99.33%
Git Operations	Operational	99.99%
Webhooks	Operational	99.99%
Pages	Operational	99.65%
Packages	Operational	100.0%
Codespaces	Operational	99.97%
Copilot AI Model Providers	Operational	99.88%

Those uptime figures moved measurably across the afternoon. Actions fell from 99.39% to 99.33%, API Requests from 99.87% to 99.82%, and Issues and Pull Requests from 99.94% to 99.88%. Roughly three hours of downtime was written into GitHub's 90-day record in a single sitting.

The omission is worth dwelling on. GitHub's 16:59 update named seven services individually and said nothing about Copilot, yet Copilot is the one component its own dashboard still flags as a Major Outage. Either it recovered on a separate track that GitHub has not described, or it was left out by oversight. GitHub has not clarified which.

What Is Broken and What Still Works

Beyond the headline services, GitHub confirmed during the incident that SAML and OIDC authentication, SCIM provisioning, and Team Sync were affected. For enterprise customers that was the most disruptive part — organisations using single sign-on saw developers unable to authenticate at all, and automated user provisioning stopped flowing. GitHub's mitigation update did not address these separately, so treat SSO as recovered alongside the core services rather than confirmed independently.

Copilot is now the outlier. The Copilot AI model providers stayed operational for the whole incident, so whatever is keeping Copilot itself down sits in GitHub's own authorisation and routing layer rather than with any upstream AI provider. Packages and Codespaces were never affected at all.

Full Timeline of the GitHub Outage

All times 17 August 2026. UTC first, IST in brackets.

13:40 UTC (19:10 IST) GitHub opens the incident, reporting impacted performance for some services.
13:41 UTC (19:11 IST) API Requests degraded.
13:42 UTC (19:12 IST) Actions degraded.
13:44 UTC (19:14 IST) Webhooks degraded.
13:45 UTC (19:15 IST) GitHub quantifies it for the first time — a roughly 20% error rate across Pull Requests, Issues and other experiences.
13:46 UTC (19:16 IST) Issues degraded.
13:58 UTC (19:28 IST) Pull Requests degraded.
14:04 UTC (19:34 IST) Scope widens: 20% error rate on web and API traffic, and around 50% on archive downloads and raw repository content. Root cause still unknown.
14:24 UTC (19:54 IST) SAML and OIDC authentication, SCIM and Team Sync added to the impact list.
14:31 UTC (20:01 IST) Copilot degraded.
14:45–14:58 UTC (20:15–20:28 IST) Pull Requests, Issues, Actions and Webhooks are each escalated from degraded performance to degraded availability.
14:58 UTC (20:28 IST) GitHub says it is applying mitigations based on its investigation so far and monitoring for improvement.
15:01 UTC (20:31 IST) API Requests escalated to degraded availability.
15:10 UTC (20:40 IST) Pages degraded.
15:21 UTC (20:51 IST) Git Operations degraded — the first sign that core clone, fetch and push traffic is affected.
15:42 UTC (21:12 IST) Impact figures unchanged. GitHub says it is applying mitigations.
16:16 UTC (21:46 IST) More than two and a half hours in, GitHub states it is still working to identify the root cause — the error rates are unchanged from the 14:04 update.
16:36 UTC (22:06 IST) The turn. GitHub says it has identified the problematic component, taken corrective action, and is seeing "strong signs of recovery", with error rates still slightly elevated.
The incident remains open.
16:59 UTC (22:29 IST) GitHub declares the degradation affecting API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks mitigated, and moves to monitoring. All seven return to Operational. Copilot is absent from the update and stays at Major Outage.

Has GitHub Said What Caused It?

Partly. At 16:36 UTC, nearly three hours into the incident, GitHub said it had identified the problematic component and applied corrective action. It has not said what that component is.

The wording matters. Twenty minutes earlier, at 16:16 UTC, GitHub was still reporting that it was working to identify the root cause, with error rates unchanged from where they had sat since 14:04. Between those two updates, engineers found something and pulled it. Identifying a faulty component is not the same as understanding why it failed, so a full root cause analysis is still pending — GitHub publishes these for most significant incidents, usually within a few days.

The shape of the failure was informative even before that. Error rates were partial rather than total, consistent at around 20% for web and API traffic, with content-serving paths failing at more than double that rate. That pattern points to a subset of infrastructure — a shard, a cluster, a region or a degraded dependency — rather than a total collapse, which is why some users reported GitHub working normally while others could not load a pull request.

GitHub's August 2026 Reliability Record

This is not an isolated bad day. Today's incident is the 13th separate incident GitHub has logged in the first 17 days of August 2026, spread across nine different days. The pattern is more revealing than any single outage:

Date	Incident	Documented cause
3 Aug	Copilot chat and agent errors, ~4,066 users affected in one hour	Model-list requests exceeded an internal rate limit
5 Aug	100% of new Copilot cloud agent jobs are delayed for 52 minutes	Rate limit applied more broadly than intended
6 Aug	GitHub Pages — around 128,000 deployments not processed	The configuration change cut processing capacity
6–7 Aug	Actions down over 9 hours; 71% of workflow runs failing at peak	Routine deployment exposed a capacity and concurrency weakness
10 Aug	Fine-grained personal access tokens silently failed to create	The front-end JavaScript change broke the confirmation step
11 Aug	GraphQL API timeouts	Resource contention from high utilisation at one site
12 Aug	500 errors on Pull Requests, Issues, and Search	Query hint pointed at an index that a migration had removed
12 Aug	Log in and release asset download failures	Not published
13 Aug	Three incidents — Webhooks, Copilot models, GHEC Team Sync	Background job, upstream provider, sync degradation

Two themes run through almost all of them: capacity headroom and change management. Configuration changes and routine deployments repeatedly pushed services past limits that were not being monitored closely enough to catch before customers did. GitHub's own write-up of the 6 August Actions failure conceded that its availability metrics had not fully captured the impact.

The cost shows in the 90-day uptime figures. Actions sits at 99.33%, which works out to roughly 14 and a half hours of downtime in 90 days — an order of magnitude worse than the 99.99% that Git Operations and Webhooks maintain. Pages at 99.65% translates to about seven and a half hours. For teams whose deployment pipeline runs entirely on Actions, that is a meaningful business risk, not a rounding error.

What Developers Should Do Right Now

Check Copilot separately. Everything else is mitigated, but Copilot is still marked as a Major Outage and GitHub has given no timeline for it. If chat or agent features are failing in your IDE, that is the incident, not your configuration.

Assume workflow triggers are being lost. In the 6 August Actions incident, GitHub confirmed that push and pull request events dropped during the outage could not be replayed automatically — affected users had to push a new commit or re-run workflows manually. Audit your workflow runs from the 13:40–16:59 UTC window now and re-trigger anything that never fired.

Pin your dependencies elsewhere if you can. Builds that fetch tarballs or raw files from GitHub during the build step are failing roughly half the time. If you have a package registry mirror or vendored dependencies, use them until this clears.

Enterprise SSO admins should hold off on user provisioning changes. SCIM and Team Sync are affected, so team membership changes made now may not apply correctly or may apply late.

Do not force-push or run migrations against a repository during degraded Git operations. Partial failures during write operations are the worst time to be doing anything irreversible.

How to Check GitHub Status Yourself

The canonical source is GitHub status. GitHub Enterprise Cloud customers should check their regional page instead, because these track separate infrastructure: GitHub US, GitHub EU, GitHub AU, and GitHub JP.

For automated monitoring, GitHub publishes an Atom feed and an RSS feed of incident history, and supports email, SMS, Slack, and webhook notifications. Teams that depend on GitHub for deployments should wire the webhook into their own alerting rather than finding out from a failed build.

Official status pages tell you what a vendor has admitted to. They do not tell you what is breaking for people in your region, on your ISP, or in the specific corner of the product you happen to use. For that side of the picture, our sister site Downbits runs a GitHub outage tracker where you can see what other developers are reporting and add your own report — API, login, website or DNS. If Git operations are failing for you but the status page still says degraded rather than down, that gap is worth logging.

Disclosure: Downbits is operated by the Cyber Kendra team.

Related: this is the second major infrastructure failure to hit developers and site owners this month. See our full coverage of the Namecheap outage, which took hosting and DNS offline for more than 30 hours after a cooling failure at its Phoenix data centre.

Frequently Asked Questions

Is GitHub down for everyone?

No. This is a partial outage with roughly a 20% error rate on web and API traffic, so many requests still succeed. Whether you notice it depends on which service you are using and how lucky your individual requests are.

When will GitHub be back up?

Most of it already is. GitHub mitigated the degradation across API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks at 16:59 UTC and moved to monitoring. Copilot was left out of that update and is still marked as a Major Outage, with no separate timeline given.

Are git push and git clone working?

Yes. Git Operations was degraded from 15:21 UTC and confirmed mitigated at 16:59 UTC. Clone, fetch and push are back to normal, and were never fully down.

Are my repositories or data at risk?

Nothing GitHub has published points to data loss or a security incident. This is an availability problem, and no breach or compromise has been indicated.

Why is GitHub Copilot not working?

Copilot is the one service that has not recovered. GitHub's 16:59 mitigation update covered seven other services and omitted Copilot, which is still marked as a Major Outage. The Copilot AI model providers are operational, so the failure is in GitHub's own service layer rather than the underlying models.

Is this related to Microsoft or Azure?

GitHub has not attributed the incident to any upstream provider, and no Azure connection has been stated. Treat any such claim as unconfirmed until GitHub publishes a root cause analysis.

Updates

2026-08-17, 16:59 UTC (22:29 IST) — GitHub declares the degradation mitigated across API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks and moves to monitoring. All seven show Operational. Copilot is not mentioned and remains at Major Outage. The incident is not yet resolved.

2026-08-17, 16:36 UTC (22:06 IST) — GitHub has identified the problematic component and applied corrective action, reporting strong signs of recovery with error rates still slightly elevated. The component it found has not been named. The incident remains open and the status dashboard still shows five services in Major Outage.

2026-08-17, 16:16 UTC (21:46 IST) — GitHub says it is still working to identify the root cause. Error rates unchanged.

2026-08-17, 15:42 UTC (21:12 IST) — Incident ongoing. Five services in Major Outage. GitHub applying mitigations, no root cause published. Error rates approximately 20% for web and API, and 50% for archive downloads and raw content.

This is a developing story. We are tracking GitHub's status page and will update this post as recovery continues and when GitHub publishes its root cause analysis.

Microsoft's SCCM Hotfix Fixes Only One of Four RCE Bugs

protalweb@gmail.com (Vivek Gurung) — Sun, 16 Aug 2026 21:49:36 +0530

Security researcher Omri Baso has disclosed a remote code execution chain in Microsoft Configuration Manager (SCCM/ConfigMgr) that lets an ordinary Active Directory user seize SYSTEM control of a Primary Site Server — and every client it manages. Microsoft has patched only one link in that chain, CVE-2026-47301, leaving the full path to code execution open until a later release.

CVE-2026-47301 is a missing role-based access control (RBAC) check in the SCCM AdminService REST API. SentinelOne's advisory rates it at CVSS 8.8 (High) under CWE-284, improper access control; Microsoft rates it as an elevation-of-privilege flaw.

On its own, it is the entry point, Baso — a researcher at XM Cyber — chained with three still-unpatched bugs to run code as NT AUTHORITY\SYSTEM. He reported the chain to Microsoft on 23 May 2026 and says roughly 100 million SCCM clients are managed worldwide.

How the SCCM Exploit Chain Works

The AdminService exposes two console-extension upload endpoints. UploadExtension enforces a permission check; its chunked twin, UploadExtensionInChunks, does not — that gap is CVE-2026-47301, and it lets any authenticated domain user submit a malicious CAB archive without holding a single SCCM role.

From there, the chain runs through three flaws Baso detailed publicly: a path-traversal bug he named CabSlip, which lets files inside the CAB escape the extraction folder and write anywhere the service can reach; weak Authenticode validation that accepts any non-revoked code-signing certificate — including a $58 commercial one — because revocation checking is skipped on that path; and an insecurely loaded DLL adsource.dll, pulled in every few minutes by the SYSTEM-level smsexec.exe (SMS Executive) process. Planting a malicious adsource.dll in the install directory turns the file write into reliable SYSTEM code execution on the site server. It mirrors the partial-fix pattern seen in Microsoft's recent SharePoint RCE chain (CVE-2026-63520).

Which SCCM Versions Are Affected?

Configuration Manager (current branch)	Status	Fix
Version 2603	Affected	KB38232642 (in-console)
Version 2509	Affected	Second 2509 update rollup (KB37864969)
Version 2503	Affected	KB38232642, requires rollup KB32851084

Has Microsoft Patched It?

Microsoft addressed the broken-access flaw in hotfix KB38232642, available in the Updates and Servicing node for version 2603, for 2503 with update rollup KB32851084 installed, and rolled into the second 2509 update rollup — no separate out-of-band hotfix is needed there. The update requires no computer restart or site reset.

The fix removes the any-domain-user route, but not the chain. The other three flaws stay unpatched until ConfigMgr 2609, expected in October 2026. A user holding the built-in Operations Administrator role — or any custom role with Create (1024) on SMS_ConsoleExtensionData — can still reach the same RCE through UploadExtension. XM Cyber judges that route lower risk, since Operations Administrator is already a highly privileged role. It is the second time in weeks that Microsoft has shipped a fix that closes only part of a disclosed issue, after it left a Windows passkey prompt spoofing flaw unaddressed.

How to Detect SCCM CVE-2026-47301 Exploitation

Failed extraction attempts leave a trail. Check <InstallationDir>\Logs\AdminService.log for a System.IO.DirectoryNotFoundException followed by a 500 Internal Server Error — the folder GUID changes on each run, so match the pattern, not the exact string. Beyond that, forward SMS Provider and AdminService logs to your SIEM and alert on authenticated AdminService requests from non-administrative hosts, console role or security-scope changes made by low-privileged accounts, and unexpected new administrative assignments.

There is no public report of in-the-wild exploitation, and the flaw is not in CISA's KEV catalog, though Baso's full exploit suite is on GitHub. Both Microsoft's guidance and the researcher recommend restricting access to the AdminService port on administrative subnets via a firewall as the most reliable containment measure until the chain is fully closed.

Frequently Asked Questions

What is CVE-2026-47301?

It is a missing RBAC check in the SCCM AdminService's chunked console-extension upload endpoint, allowing any domain user to submit a CAB archive without an SCCM role. It is one link in a four-flaw RCE chain.

Does KB38232642 fully fix the SCCM RCE?

No. KB38232642 patches only CVE-2026-47301 — the broken-access entry point. The path traversal, weak signature check, and DLL hijack remain unpatched until ConfigMgr 2609 in October 2026.

Which SCCM versions need patching?

Configuration Manager current branch versions 2503 (with rollup KB32851084), 2509, and 2603.

Namecheap Outage Hits Hosting, DNS and Private Email

protalweb@gmail.com (Vivek Gurung) — Fri, 14 Aug 2026 00:25:46 +0530

INCIDENT RESOLVED — updated 14 August 2026
RESOLVED — 14 August 2026, 17:00 UTC. Namecheap has declared the incident closed. All hosting, EasyWP, DNS, Private Email and support services are back online after 30 hours 32 minutes.
The cause was a major storm that knocked out cooling at the RadiusDC Phoenix data center. RadiusDC instructed Namecheap to power services down to protect hardware. Namecheap reports no data loss and says it will add redundancy across its US, European and Asian data centers. Full timeline and updates below.

Websites, business email, and DNS for a large slice of Namecheap's customer base went dark on 13 August 2026 after the cooling system at the Phoenix data center hosting the company's core infrastructure failed. By Namecheap's own count, more than 5,000 servers were taken offline — not by the failure itself, but by a deliberate shutdown to stop hardware cooking in a data hall that had lost its chillers.

The blast radius is wider than that of most outages at a hosting provider because Namecheap's authoritative DNS servers sit within the same failure domain. That means sites hosted elsewhere broke too, as long as their nameservers pointed to Namecheap. And because the support helpdesk lives in that same building, customers could not open a ticket to ask what was happening.

What Is Actually Broken

Namecheap's status post explicitly lists the affected services. This is the full scope as the company described it:

Service	Reported impact
namecheap.com	Site under emergency maintenance; account dashboard unreachable
Shared, VPS & Dedicated hosting	Sites unavailable, slow, or returning 503 errors; cPanel/hosting panel inaccessible
Namecheap DNS	Zone resolution and zone management unavailable
EasyWP	Entire platform affected — EasyWP.com, the dashboard, and customer sites
Private Email	Intermittent; incoming and outgoing delivery both disrupted
Mail forwarding	Free Email Forwarding and Domain Privacy forwarding both hit
URL Redirect	Affected on both BasicDNS and PremiumDNS
Support helpdesk	Unable to process email tickets; live chat pushed as the fallback
Hosting operations	Activations, renewals, and plan changes are being processed with delays

One detail from the original advisory went largely unreported: with both live chat and email ticketing down, Namecheap moved customer support to Microsoft Teams, publishing a list of backup Teams accounts split by department — separate handles for domains, hosting, SSL, transfers, managed WordPress, Private Email, billing and abuse. It was an improvised channel for an outage that had taken out the normal ones, and most customers never saw it because the page announcing it was itself hard to reach.

Independent outage trackers put the user-reported breakdown at roughly 60% hosting, 30% domains, and 10% cloud services, with reports arriving from Mexico, Vietnam, Uruguay, and across Europe — consistent with a single-origin failure rather than a regional network problem. Live user reports are aggregated on Downbits' Namecheap status page, which also lets you file a report if your own services are affected.

Timeline of the Namecheap Outage

All times below are UTC, with Indian Standard Time in brackets. The sequence matters because the data center operator flagged the problem roughly two hours before Namecheap told customers anything.

Time	Event
10:28 UTC (15:58 IST)	PhoenixNAP opens an incident titled “Higher ambient temperature in the Phoenix DC”, noting no critical service impact
11:28 UTC (16:58 IST)	PhoenixNAP moves the incident to Identified, warning that the equipment may reboot
11:42 UTC (17:12 IST)	Namecheap posts a separate notice about EasyWP servers being unreachable
~12:20 UTC (17:50 IST)	Third-party trackers register the start of mass user reports
12:35 UTC (18:05 IST)	Namecheap publishes its emergency maintenance status post, citing a power outage
~12:40 UTC (18:10 IST)	Namecheap confirms the disruption on X; states there is no ETA
13:04 UTC (18:34 IST)	PhoenixNAP reports its facilities team is working with an on-site vendor, still no ETA
Later, 13 Aug	CEO Hillan Klein states 2 of 4 chillers are back, temperatures are dropping, and a third is expected within roughly three hours
21:30 UTC (03:00 IST, 14 Aug)	Status page confirms core databases, core virtualisation, most core network equipment, internal source control and all major load balancers back online
22:10 UTC (03:40 IST, 14 Aug)	Namecheap.com and Live Chat back online — 11 hours 42 minutes after the first data centre alert
23:50 UTC (05:20 IST, 14 Aug)	Account access, domains and DNS management restored. Shared hosting past 50%, VPS past 30%, dedicated servers returning. Email still down, no ETA
01:34 UTC, 14 Aug (07:04 IST)	Email help system up. Private Email sending and receiving operational on legacy and new plans. Dedicated servers fully back. VPS past 90%, shared hosting past 80%. EasyWP.com and Dashboard operational, client websites still affected
03:00 UTC, 14 Aug (08:30 IST)	All affected VPS packages up and running. Shared and reseller hosting past 90%. Many EasyWP client sites accessible; sites on two named ALIAS records still affected
07:50 UTC, 14 Aug (13:20 IST)	All EasyWP services up. Shared and Reseller Hosting fully back online. Namecheap begins reviewing all services
09:05 UTC (14:35 IST)	MySQL stopped for maintenance on Premium Server 126 and Premium Server 247; sites on those hosts show database errors. Window given as 4–6 hours per host
12:55 UTC (18:25 IST)	Some VPS and dedicated servers found still unreachable or returning 503 errors; VPS investigated globally, dedicated case by case
13:19–13:34 UTC (18:49–19:04 IST)	MySQL recovered on both Premium Servers, with no data loss
15:15 UTC (20:45 IST)	All affected VPS Hosting packages back online
17:00 UTC (22:30 IST)	Namecheap declares the incident resolved — 30 hours 32 minutes after the first data centre alert

How Long Was Namecheap Down?

For the main site, 11 hours 42 minutes — from PhoenixNAP's first temperature alert at 10:28 UTC on 13 August to Namecheap confirming namecheap.com back online at 22:10 UTC. Measured from Namecheap's own first customer notice at 12:35 UTC, it is 9 hours 35 minutes.

End to end, the incident ran 30 hours 32 minutes — from 10:28 UTC on 13 August to Namecheap declaring it resolved at 17:00 UTC on 14 August. Measured from Namecheap's own first customer notice, 28 hours 25 minutes.

Recovery was staggered, so no single number describes what any given customer experienced. Live Chat was unreachable for roughly ten hours. Namecheap.com returned at 11 hours 42 minutes. EasyWP client sites took until 07:50 UTC on 14 August. Some VPS and dedicated servers were still unreachable at 12:55 UTC, more than 26 hours in, and shared hosting customers on two Premium Servers hit a fresh database outage on the second day. If you need a figure for an SLA claim, use your own monitoring timestamps rather than any headline number.

Restoration Progress by Service

Service	Status
namecheap.com	Online since 22:10 UTC. Account access, domains and DNS management restored
Live Chat	Online since 22:10 UTC
Email help system	Up and running — ticket submission working again
Dedicated Servers	Back online
VPS Hosting	All affected packages up and running
Shared Hosting	More than 90% back online
Reseller Hosting	More than 90% back online
Private Email	Outgoing and incoming delivery operational on legacy and new plans (Launch, Scale, Expand). Outage-period mail may still arrive delayed
EasyWP	Partly affected. EasyWP.com and Dashboard fully operational, many client sites accessible. Sites on two specific ALIAS records still down
Spaceship VPS, Shared & Spacemail	Back online

Everything in the table above is now restored. Recovery ran roughly in inverse order of abstraction: raw dedicated hardware and VPS returned first, shared and reseller hosting followed, and EasyWP — the most heavily managed platform, with the most layers between customer and metal — came last, in two stages.

EasyWP Database Connection Errors Explained

EasyWP recovered in two stages, and the gap between them confused a lot of customers. EasyWP.com and the Dashboard came back at 01:34 UTC while client websites were still down — so people logged in, saw their site listed as running, loaded the domain, and got nothing.

At 03:00 UTC Namecheap did something unusually specific: it named the exact infrastructure still affected. Sites pointed at these ALIAS records were the ones returning Error establishing a database connection:

ALIAS record	Resolves to
ingress-baronn.ewp.live	63.250.43.9 \| 63.250.43.10
ingress-cinna.ewp.live	63.250.43.11 \| 63.250.43.12

All EasyWP services were confirmed fully restored at 07:50 UTC on 14 August. If your EasyWP site is still unreachable now, it falls outside what Namecheap has described and is worth a ticket rather than self-diagnosis.

Two separate MySQL incidents followed on shared hosting: Premium Server 126 and Premium Server 247 had MySQL stopped for maintenance at 09:05 UTC, with sites on those hosts showing database errors for several hours. Both recovered by 13:34 UTC, and Namecheap confirmed no data was lost in either case.

Do not restore from a backup. Your files and database are almost certainly intact; the serving layer is what is missing. A restore solves nothing and risks overwriting good data with older data.
Do not delete and recreate the site from the dashboard.
Do not repoint DNS away from EasyWP mid-restoration. You will chase propagation for hours on a site that would have come back on its own.
Do not reinstall plugins or WordPress core to fix a site you cannot reach.

Restoring from a backup during that window was the single worst thing an affected owner could have done. A database connection error means the database layer is unreachable, not that data is damaged — a restore would have overwritten intact data with older data for no benefit.

What Actually Caused the Namecheap Outage

During the incident Namecheap gave customers two different causes, and the discrepancy went uncorrected for more than a day. Its post-incident communication finally reconciled them.

One naming note worth clearing up first, because coverage has split on it. The facility is the same building under two names: RadiusDC acquired PhoenixNAP's Phoenix data center and colocation business in a deal announced on 12 March 2026, with the site becoming RadiusDC's Phoenix I campus and PhoenixNAP remaining as a tenant. That is why PhoenixNAP's own status page logged the same ambient-temperature incident while Namecheap's communications name RadiusDC. There is no indication the ownership change contributed to the failure.

The status post and the company's X account both attribute the incident to “emergency maintenance due to a power outage affecting our datacenter in Phoenix”.

Namecheap CEO Hillan Klein, posting publicly the same day, described something different: an infrastructure incident at PhoenixNAP where “the facility has suffered a failure of its cooling systems”. He said Namecheap then chose to power services down to prevent overheating and long-term hardware damage.

PhoenixNAP's own status page supports the CEO's version, not the status post's. Its incident is titled around ambient temperature, and its updates describe chillers and a cooling vendor — there is no mention of a utility power failure.

Namecheap's post-incident communication settled it. A major storm knocked out cooling at the RadiusDC Phoenix facility, driving temperatures to unsafe levels. That reconciles both accounts: a storm-driven power event took the chillers down, and the chiller loss forced a thermal shutdown.

Two details from that account correct what was reported during the incident, including here. First, the decision to power down was not Namecheap's own call — RadiusDC instructed Namecheap to take services offline to protect customer infrastructure. Second, staying offline until conditions were safe was itself part of the recovery strategy, not just a consequence of the failure.

The distinction between a power outage and a cooling failure was never academic. A power outage implies infrastructure that returns when the lights do. A thermal shutdown is slower, because you cannot safely repower thousands of servers until the hall has actually cooled. That is why this ran for a day and a quarter rather than minutes.

Namecheap's status post was also quietly revised. It originally attributed the incident to a power outage; the current version describes a cooling failure. No correction notice was attached to the change.

No, There Is No Confirmed DDoS Attack

Several outlets and aggregator sites have published headlines pairing this outage with a distributed denial-of-service attack. Some framed it as Namecheap being hit by a DDoS and a power outage simultaneously.

Cyber Kendra checked every primary source available for this incident: Namecheap's status post, its X account, its CEO's public statement, and PhoenixNAP's status page. None of them mentions a DDoS attack. Every official account points to a facility-level cooling or power problem.

The DDoS framing appears to be a carryover from a separate Namecheap incident in February 2024, when the company confirmed a DDoS affecting its main site and support systems. It has also experienced DDoS-related disruption on a dedicated server earlier in 2026. Those were real events. They are not this one.

Some customers on social platforms have alleged that Namecheap initially communicated a DDoS before switching to the power-outage explanation. Cyber Kendra has not been able to verify that claim against any archived Namecheap communication, and it should be treated as unconfirmed. If you are reading a report that attributes this outage to an attack, check whether it cites a Namecheap source or another news article.

Will I Lose Email, Files, or Data?

On email, Namecheap has been specific, and the explanation is technically sound. Mail sent to affected addresses during the outage is not expected to be lost. When a receiving mail server is unreachable, the sending server queues the message and automatically retries over a period that can last for days. Once connectivity returns, the backlog delivers. What you should expect is delay, not loss.

The exceptions worth knowing:

Senders whose mail servers give up early, or which bounce on the first timeout, may generate a delivery failure notice. Those messages will not arrive on their own.
Anything time-sensitive that routed through Namecheap forwarding — password resets, OTPs, payment confirmations, calendar invites — may arrive too late to be usable, even if it eventually arrives.
Mail you were composing in webmail at the moment of the cutoff is gone unless it was saved as a draft on the server.

My Namecheap inbox is empty. Are my old emails gone?

As services returned, multiple users reported logging into webmail successfully and finding their mail missing. One asked CEO Hillan Klein publicly whether a day of incoming mail was simply gone, then confirmed after his reply that login and iOS access worked normally while nothing arrived.

Klein's answer at the time was that email services were not fully back and mail would be restored once the remaining infrastructure came up. That is what happened. A staged restart brings authentication and webmail front-ends back before the mail storage behind them, so a login succeeds against a mail store that is not yet online and presents as an empty inbox. It was not deleted mail. Private Email is now sending and receiving on both legacy and new plans.

If your mailbox still looks wrong:

Give it time. Namecheap says outage-period mail may still be delayed, and queued backlogs from external senders deliver over hours, not seconds.
Do not delete and re-add the account in Outlook, Thunderbird or Apple Mail while a backlog is landing — your client's local cache may hold the most complete copy.
If you use POP3 without leaving copies on the server, your local store is the authoritative copy. Back it up before touching anything.
Shared hosting mailboxes are separate from Private Email. If your hosting is in the remaining percentage, your mail is too.
If mail is still missing once the backlog settles, raise a ticket — the email help system is working again.

What about my website data?

On hosting data, a thermal shutdown is a controlled power-down, which is the safest kind. Namecheap has not reported data loss and has not indicated that any storage was damaged. That said, an unplanned shutdown of thousands of machines can leave individual databases in an inconsistent state on restart. When your site comes back, check that recent writes — orders, form submissions, new posts — are actually present before assuming everything restored cleanly.

What Namecheap Users Should Do Right Now

Do not start a domain transfer yet. Transfers need working registrar systems and a reachable admin email. With mail backlogs still clearing, an auth code or approval message can arrive late enough to stall the transfer.
Do not change nameservers in a panic. A half-applied nameserver switch during propagation can extend your downtime well past the outage itself.
Support is working again. Email ticketing was down for most of the incident and live chat was the only channel. Both are restored, so a ticket is now the better route for anything needing a paper trail — particularly an SLA credit request.
Tell your own customers before they tell you. If you host client sites, a short factual notice naming the upstream cause protects you far better than silence. Link to the vendor status page, not to your own guesswork.
Screenshot everything. Uptime monitor logs, error pages, timestamps, and lost transaction records. If you intend to ask for a credit, the case is built on evidence you collect now, not on your recollection next week.
Check your recent data once you are back. Verify the last few hours of database writes before the outage, and confirm scheduled jobs and cron tasks resumed.

The Design Decision That Made This Worse

Most coverage of this outage stops at “data center had a problem”. The more useful question is why a single facility could take out this much surface area at once.

Namecheap has been a major tenant of the same Phoenix building for years, first under PhoenixNAP and now under RadiusDC. In its own public post-mortem after a 2018 outage at the same facility, the company described itself as one of the site's largest tenants, drawing around half a megawatt and running thousands of servers there. The 5,000-plus figure cited this week suggests that concentration has not meaningfully changed.

Concentrating hosting in one well-run facility is a defensible business decision. Concentrating authoritative DNS in the same failure domain as the hosting it serves is a different matter. DNS is the one service in the stack that is supposed to be geographically distributed precisely so that it survives the loss of any single site. When Namecheap DNS went down, it did not just break Namecheap-hosted sites — it broke every site anywhere in the world whose nameservers pointed at Namecheap, including sites hosted on entirely unaffected providers.

The support helpdesk sitting in the same building compounds the problem. The moment customers most needed to reach Namecheap was the moment Namecheap could not receive tickets. Status communication then falls back to X, which is not where most customers look first.

For readers who host with Namecheap, the practical takeaway is narrower than “switch providers”. It is this: your DNS provider and your hosting provider should not be the same company on the same site. Moving authoritative DNS to an independent, anycast provider costs nothing on most free tiers and decouples the two largest failure modes you are exposed to. Had that separation been in place, a large share of the sites that broke this week would have remained resolvable, served an error from their origin, and been fixable with a temporary redirect.

Namecheap's Track Record at Phoenix

This is not the first significant incident at the same facility, and the pattern is part of why the reaction from longtime customers was so sharp.

November 2018 — A power failure at PhoenixNAP during UPS maintenance caused route flapping on Namecheap's core network. The company published a detailed post-mortem noting that some non-critical infrastructure was not designed to be power-redundant.
August 2020 — A prolonged outage hit namecheap.com, shared hosting, VPS, EasyWP, and Private Email; Namecheap ultimately attributed it to a third-party upstream provider.
September 2021 — A misconfiguration during network expansion triggered a network storm that took down a redundant firewall cluster. Namecheap's post-mortem conceded that its first response had been based on an incorrect assumption, costing it hours.
February 2024 — A confirmed DDoS campaign affected the main site and customer support.
July 2026 — Shared and VPS hosting in Phoenix experienced timeouts, with restoration staged across servers.

Read together, these are not all the same failure. But four of the five involve the Phoenix footprint, and the recurring theme in Namecheap's own post-mortems is redundancy that existed on paper failing to hold at the edges.

What Namecheap Says It Will Change

In the email sent to customers after resolution, Namecheap committed to examining the incident in detail and adding further redundancy across its data centers in the US, Europe and Asia. It also said it would publish what it learns and the actions it takes.

That is the right response to this failure mode, and it is worth holding the company to. The problem this outage exposed was not that a data center failed — data centers fail — but that too much sat in one of them, including services like authoritative DNS that exist specifically to survive the loss of any single site. Geographic redundancy across three continents addresses exactly that, if it is implemented for DNS and not only for hosting.

Namecheap published detailed post-mortems after its 2018 and 2021 incidents. Whether a comparable document follows this one is the thing to watch, and Cyber Kendra will update this page when it appears.

Can You Claim Compensation?

Namecheap had not announced any compensation, service credit, or SLA payout at the time of writing, and customers were publicly asking for one.

What is worth knowing before you ask: hosting SLA credits generally have to be requested rather than applied automatically, are usually calculated as a proportion of the monthly fee rather than your business losses, and are typically defined in the hosting terms rather than the general terms of service. Read the SLA terms attached to your specific plan — shared, VPS, dedicated, and EasyWP are not necessarily covered identically — and file the request through the ticket system once it is processing email again, with your monitoring logs attached.

Cyber Kendra is not a legal advisor, and consequential losses from downtime are usually excluded by hosting contracts. If the sums involved are material to your business, that is a conversation for a lawyer rather than a support ticket.

Frequently Asked Questions

Is Namecheap down right now?

Almost fully restored. Namecheap.com, Live Chat, the email help system, DNS management and Private Email are back. All affected VPS packages are running, dedicated servers are restored, and shared and reseller hosting are past 90%. Some EasyWP client websites remain affected. Namecheap has not declared the incident fully resolved. For crowd-sourced reports from other users, see Downbits.

Why is Namecheap down?

A major storm knocked out cooling at the RadiusDC Phoenix data center, driving temperatures to unsafe levels. RadiusDC instructed Namecheap to take services offline to protect hardware, taking more than 5,000 servers down. The facility was acquired from PhoenixNAP earlier in 2026, which is why both names appear in coverage.

Was Namecheap hacked or hit by a DDoS attack?

No primary source from Namecheap or PhoenixNAP describes an attack for this incident. Reports linking it to a DDoS appear to conflate it with a separate, confirmed February 2024 Namecheap incident.

Will I lose emails sent during the Namecheap outage?

Namecheap says messages are not expected to be lost. Sending mail servers queue and retry automatically, so mail should deliver late rather than disappear. Hard bounces from senders that give up early are the exception.

Why is my Namecheap email inbox empty after the outage?

Email infrastructure was restored in stages, so webmail login returned before the mail storage behind it. That produced mailboxes that opened but appeared empty. Private Email is now sending and receiving on both legacy and new plans, though outage-period mail may still arrive delayed.

How long was Namecheap down?

30 hours 32 minutes end to end, from the first data centre alert at 10:28 UTC on 13 August to Namecheap declaring resolution at 17:00 UTC on 14 August. The main site itself was unreachable for 11 hours 42 minutes; EasyWP and some VPS and dedicated servers took considerably longer.

My EasyWP site shows “Error establishing a database connection”. Why?

Because your site sits on one of two ingress groups Namecheap has confirmed are still affected: ingress-baronn.ewp.live (63.250.43.9, 63.250.43.10) and ingress-cinna.ewp.live (63.250.43.11, 63.250.43.12). Run a DNS lookup on your domain to check. If it resolves to one of those addresses, it is a Namecheap-side problem — do not restore from backup, recreate the site or repoint DNS.

Are my domain registrations at risk?

Domain registration records are stored at the registry, not on Namecheap's hosting servers, so ownership is unaffected by a data center outage. Renewals and transfers processed during the window may be delayed.

My site is hosted elsewhere, but it still went down. Why?

Because your domain's nameservers point at Namecheap DNS. Namecheap's authoritative DNS was in the same failure domain as its hosting, so name resolution failed regardless of where the site was served.

Should I move my domain away from Namecheap?

Moving registration mid-incident is more likely to create problems than solve them. The higher-value change, once services are stable, is to separate DNS from hosting so that a single provider outage cannot break both at once.

Updates

2026-08-14, 17:00 UTC — Resolved. Namecheap declared the incident closed, 30 hours 32 minutes after the first data centre alert. Cause confirmed as a major storm knocking out cooling at the RadiusDC Phoenix data center, with RadiusDC instructing Namecheap to power services down. No data loss reported. Namecheap has committed to adding redundancy across its US, European and Asian data centers. No compensation announcement; no post-incident report yet.

2026-08-14, 15:15 UTC — All affected VPS Hosting packages back online.

2026-08-14, 07:50 UTC — All EasyWP services restored. Shared and Reseller Hosting fully back. Separate MySQL maintenance on two Premium Servers followed, recovered by 13:34 UTC with no data loss.

2026-08-14, 03:00 UTC — All affected VPS Hosting packages up and running.

2026-08-13 — Article published during the active outage.

This page is updated as the incident progresses. Bookmark it rather than searching again.
Disclosure: Downbits, linked above, is operated by Cyber Kendra.

Apple Warns iPhone Users of Mercenary Spyware Attacks

protalweb@gmail.com (Vivek Gurung) — Fri, 14 Aug 2026 09:23:36 +0530

Apple sent a fresh round of mercenary spyware threat notifications to users in 110 countries on Thursday, and for the first time, the warning lands as a push alert on the iPhone Lock Screen instead of an email that can sit unread for a week. Apple confirmed the round's scale to TechCrunch and published a revised support page describing the new delivery method the same day.

The delivery change is the part that matters. Apple has issued these alerts since 2021 and has now reached users in more than 150 countries, but the warnings travelled through email, iMessage, and a banner buried on the Apple Account website — channels that at-risk people routinely miss, filter as spam, or dismiss as phishing. A Lock Screen banner backed by a permanent row in Settings removes that excuse. Whether someone acts on the alert is now a decision rather than an accident.

What Changed in How Apple Sends Threat Notifications

Apple's updated support document lists four delivery channels for a threat notification:

An Apple Threat Notification alert on the iPhone Lock Screen
A dedicated Apple Threat Notification row near the top of Settings, carrying a red badge
An email from threat-notifications@email.apple.com
A banner at the top of the user's Apple Account page after signing in at account.apple.com

Two details on that page are easy to skim past. First, Apple states that notification types may vary by device model and software version, which means the Lock Screen alert is not guaranteed for everyone — users on older hardware or older iOS builds may still receive only the email notification. Second, Apple's current page no longer lists iMessage as a delivery channel, even though earlier rounds were sent that way. Apple told TechCrunch it had reworked the experience so that recipients can reach the recommended next steps more quickly.

John Scott-Railton, a senior researcher at the University of Toronto's Citizen Lab, was the first to publicly flag the new round and described the push alerts as a significant improvement. He told TechCrunch that notifications "create a critical signal that a community is being targeted", because a handful of recipients seek help, and those requests usually open investigations that surface far more victims than the original alert reached.

What the Apple Threat Notification Actually Says

The Lock Screen alert is titled Apple Threat Notification and tells the recipient that "Apple detected a mercenary spyware attack targeted at your iPhone", followed by a line saying there are actions they can take now to help protect their data and device. Tapping it opens the full advisory with recommended steps, including enabling Lockdown Mode and contacting expert help.

Apple threat notification on the Lock Screen | Image- Apple

Apple describes these as high-confidence alerts and says they should be taken very seriously, while conceding that its investigations can never reach absolute certainty. It will not explain what triggered any individual notification, because publishing detection criteria would allow spyware operators to tune their behavior to avoid detection. Apple also refuses to attribute the attacks to any government, company, or region — a deliberate position it has held through every round, including the politically explosive ones.

How to Tell a Real Apple Threat Notification From a Fake

This question matters more today than it did last week. The format of a genuine alert is now public, screenshots are circulating widely, and the population being targeted is exactly the population that will act quickly on a frightening message. Expect imitation — spoofed emails, forwarded WhatsApp screenshots, fake "spyware removal" services, and phishing pages built to look like the Apple Account banner.

Apple's own rules make verification simple:

A real threat notification never asks you to click a link, open a file, install an app or configuration profile, or supply your Apple Account password or a verification code — not by email, not on a phone call.
To confirm one, type account.apple.com into your browser yourself and sign in. If Apple sent you a notification, it appears as a banner at the top of the page. Do not use a link from the message you are checking.
Check Settings on the iPhone. A genuine notification creates its own row with a badge.
The legitimate email comes from threat-notifications@email.apple.com, but treat any sender address as weak evidence on its own. The account page is the check that settles it.

Anyone who calls, messages, or emails offering to "clean" your device after an Apple alert should be treated as hostile until proven otherwise. Apple does not provide outbound support for this, and no one outside Apple knows why you were flagged.

What to Do If You Receive an Apple Threat Notification

Do not factory reset the phone immediately. A wipe destroys the forensic traces an investigator needs to confirm what happened. Digital security responders generally ask targets to preserve the device state first.
Turn on Lockdown Mode — Settings > Privacy & Security > Lockdown Mode. Enable it on every Apple device signed into the same account, not just the iPhone.
Update to the current OS. As of August 2026, that is iOS 26.6, released on 27 July. Turn on automatic updates if they are off.
Contact the Digital Security Helpline at Access Now. It is free, runs 24 hours a day, seven days a week, and Apple points recipients to it by name. Outside organisations have no information about why Apple flagged you, but they can provide tailored advice and conduct a forensic analysis.
Secure the account from a different, trusted device. Change the Apple Account password, review every device signed in, confirm your two-factor trusted numbers, and check Settings > General > VPN & Device Management for configuration profiles you did not install.
Warn the people you talk to. If a device was compromised, the exposure includes your conversations, which means it includes sources, colleagues and family who never got an alert of their own.

A notification means Apple believes you were targeted. It is not a confirmation that the attack succeeded. Both facts are worth holding at the same time.

Every Apple Threat Notification Round Since 2021

Apple has never published a running log of these rounds, so the picture has to be assembled from its support-page revisions and from the reporting each wave generated. Here is the sequence as it currently stands.

Date	Scope	Notable detail
November 2021	First round	Programme launched weeks after Apple sued NSO Group; wording referred to "state-sponsored attackers"
31 October 2023	Global, India prominent	More than 20 Indian opposition MPs and journalists went public, triggering a political confrontation in Delhi
10 April 2024	92 countries	Apple switched its language from "state-sponsored attackers" to "mercenary spyware"
July 2024	98 countries	Second round inside four months
29–30 April 2025	100 countries	Italian journalist Ciro Pellegrino and Dutch activist Eva Vlaardingerbroek confirmed receiving alerts
Mid-2025	Iran	More than a dozen Iranian targets were alerted in the run-up to the war with Israel, as reported in July
13 August 2026	110 countries	First round delivered as an iPhone Lock Screen push; support page rewritten

Apple has never disclosed how many individuals it has notified in total, only how many countries they sit in. The country count has climbed every year the programme has run.

Does Lockdown Mode Actually Stop Mercenary Spyware?

The evidence is stronger than it was a year ago. In March 2026, an Apple spokesperson told TechCrunch the company is not aware of any successful mercenary spyware attack against an Apple device with Lockdown Mode switched on — nearly four years after the feature shipped in iOS 16.

Donncha Ó Cearbhaill, who heads Amnesty International's Security Lab and has investigated dozens of these cases, said the same: there was no evidence that an iPhone was compromised while Lockdown Mode was active at the time of the attack. Citizen Lab has separately documented instances in which Lockdown Mode blocked live attempts, including one using NSO Group's Pegasus and another using Predator.

The most persuasive endorsement came from the attackers. When Google's Threat Intelligence Group dissected the Coruna iOS exploit kit in March 2026, it found the kit checks whether Lockdown Mode or private browsing is active and quietly declines to run if either is — a design choice that only makes sense if the operators expected to fail and did not want to burn their exploits proving it.

The honest caveat: an absence of observed bypasses is not proof that none exist. Apple is tight-lipped, investigators see only what victims bring them, and a bypass held by one vendor against a handful of targets could stay invisible for years. What can be said with confidence is that Lockdown Mode removes entire classes of delivery — most message attachment types, several WebKit features, link previews, unsolicited FaceTime calls, configuration profile installation — and that shrinking the remotely reachable surface forces attackers into more expensive, more fragile chains.

The cost to a normal user is real but modest: some links have to be copied into a browser manually, some attachments will not open, and shared albums stop working. For anyone who has received a threat notification, that trade is not close.

Why India Turns Up in Every Threat Notification Cycle

India has been the most politically charged destination for these alerts since 31 October 2023, when more than 20 opposition MPs and journalists said they had received them. The named recipients included Mahua Moitra of the Trinamool Congress, AIMIM chief Asaduddin Owaisi, Congress leaders Shashi Tharoor, Pawan Khera and Supriya Shrinate, Shiv Sena (UBT) MP Priyanka Chaturvedi, and The Wire founding editor Siddharth Varadarajan.

The government's response was to question the alerts rather than the targeting. IT ministry officials publicly cast doubt on Apple's findings and announced a CERT-In inquiry into device security. The Washington Post subsequently reported that senior officials had summoned Apple representatives and pressed the company to offer alternative explanations for the warnings. Two months later, Amnesty International's Security Lab published forensic findings placing Pegasus on the iPhones of Indian journalists, including Varadarajan and Anand Mangnale of the Organized Crime and Corruption Reporting Project. When Apple ran its 92-country round in April 2024, Indian users were again among the recipients.

The legal position has not moved much. The Pegasus petitions, heard as Manohar Lal Sharma v. Union of India, remain before the Supreme Court, and the technical committee's report is still sealed. During hearings in April 2025 the bench observed orally that a country possessing spyware for security purposes is not itself objectionable and that the real question is who it is used against, while indicating the court may inform individuals whose privacy was breached rather than publish the report in full.

Which leaves a practical asymmetry worth stating plainly. No Indian law requires anyone to tell you that your phone was targeted. There is no domestic notification mechanism, no regulator that issues these warnings, and no obligation on a telecom operator or agency to disclose after the fact. For an Indian journalist, lawyer or opposition worker, an Apple threat notification is very often the only notice they will ever get that someone spent money to read their messages.

What the Attacks Look Like in 2026

Two developments this year explain why Apple is pushing harder on delivery.

February 2026 — CVE-2026-20700. Apple patched a memory corruption flaw in dyld, the dynamic linker that loads system libraries at runtime, in iOS 26.3 and the matching releases. Google's Threat Analysis Group reported it, and Apple's advisory said the issue may have been exploited in an "extremely sophisticated attack against specific targeted individuals" on versions of iOS before iOS 26. Apple linked it to CVE-2025-14174 and CVE-2025-43529, the WebKit zero-days fixed in December 2025, indicating a chain rather than an isolated bug. CISA added it to the Known Exploited Vulnerabilities catalogue.

March 2026 — the Coruna exploit kit. Google's Threat Intelligence Group disclosed a JavaScript-delivered framework containing five complete iOS exploit chains and 23 individual exploits covering iOS 13.0 through 17.2.1. Its ownership history is the alarming part: GTIG tracked it from a commercial surveillance vendor's customer, to UNC6353, a suspected Russian espionage group running watering-hole attacks against Ukrainians, and finally to UNC6691, a financially motivated Chinese actor draining cryptocurrency wallets. iVerify called it the first observed mass exploitation against iOS devices. CISA added three of the underlying CVEs to KEV on 5 March.

That trajectory is the real story of the year. A capability that cost millions and was reserved for a dozen targets ends up, a few resales later, spraying at anyone who visits the wrong website. The reasoning "I am not a journalist, so this does not concern me" held better in 2022 than it does now.

Apple's structural answer arrived in September 2025 with Memory Integrity Enforcement, built on the A19 and A19 Pro chips in the iPhone 17 line and iPhone Air using Arm's Enhanced Memory Tagging Extension. It targets the memory-corruption class that every known iOS spyware chain has depended on, and Apple's argument is not that exploitation becomes impossible but that chains become too expensive and too fragile to maintain. That is a five-to-ten-year bet, and it does nothing for the hundreds of millions of older iPhones still in circulation, which is precisely the population Coruna went after.

Guidance for Everyone Who Did Not Get an Alert

Apple's position is that the vast majority of users will never be targeted by mercenary spyware, and that is accurate. Its baseline recommendations still apply:

Keep devices on the latest software, which carries the latest security fixes
Protect the device with a passcode, Touch ID or Face ID
Use two-factor authentication and a strong, unique Apple Account password
Turn on Stolen Device Protection
Install apps only from the App Store
Use unique passwords and passkeys where available
Do not open links or attachments from unknown senders

One addition of our own: turn on automatic updates and leave them on. The Coruna campaign showed that unpatched older iPhones are now bulk targets rather than individual ones, and the gap between a patch shipping and a device receiving it is the entire window an opportunistic operator needs.

If you have not received a notification but have a concrete reason to believe you are a target — because of your reporting, your litigation, your organising or your office — Apple's advice is to enable Lockdown Mode without waiting for an alert.

Frequently Asked Questions

Is the Apple Threat Notification real or a scam?

Genuine notifications exist, and Apple has sent them since 2021. To verify yours, sign in at account.apple.com by typing the address yourself. A real notification appears as a banner at the top of the page after sign-in, and also as a dedicated row in Settings on the iPhone. Apple never asks you to click a link, install a profile, or give up your password or verification code.

Does a threat notification mean my iPhone has already been hacked?

No. It means Apple has high confidence that you were individually targeted. The attempt may have failed. Apple does not tell recipients whether the attack succeeded, which is one reason it recommends contacting a specialist who can examine the device.

Why won't Apple tell me who attacked me?

Apple does not attribute threat notifications to any attacker, company or region, and will not describe what triggered a specific alert. Its stated reason is that publishing detection criteria would help spyware operators adapt and evade future detection.

Should I factory reset my iPhone after getting an alert?

Not as a first step. A reset destroys the evidence that an investigator would use to establish what happened and whether the compromise succeeded. Preserve the device, enable Lockdown Mode, and contact the Digital Security Helpline at Access Now before wiping anything.

Does Lockdown Mode slow down or break the iPhone?

It does not affect performance. It disables features commonly abused for delivery: most message attachment types, some web technologies, link previews, unsolicited FaceTime calls and configuration profile installation. Most people find the daily cost minor compared with the exposure it removes.

How much does an expert help cost after an Apple threat notification?

Nothing. The Digital Security Helpline run by the nonprofit Access Now is free and available 24 hours a day, seven days a week. Apple points notification recipients to it directly. Treat anyone charging money to "remove spyware" after an alert as a scam.

Can Android users get similar warnings?

Google and WhatsApp both operate their own notification programmes for government-backed attack targets, though the wording, delivery and frequency differ from Apple's. There is no cross-platform standard, which is why the same person can be alerted by one company and never hear from another.

Trezor Says ShipMonk Breach Exposed 13,689 Customers

protalweb@gmail.com (Vivek Gurung) — Thu, 13 Aug 2026 21:16:20 +0530

Nearly 14,000 people who bought a Trezor hardware wallet this summer now have their names and home addresses sitting in the hands of an unknown attacker — a list that identifies them, by address, as crypto holders.

Trezor disclosed on August 13 that ShipMonk, the third-party fulfilment provider that warehouses and ships its products, reported unauthorised access to systems holding customer order data on Monday, August 10. The investigation is ongoing.

What Data Was Exposed

11,742 customers had full records exposed: full name, email address, phone number and shipping address. A further 1,947 had partial exposure limited to name, city and email — 13,689 in total. ShipMonk also stores order numbers, which lets an attacker reference a real purchase in a phishing message.

Trezor says its own systems, firmware and devices were untouched. No private keys, wallet backups or funds were involved, and operations continue normally.

Which Orders Are Affected

Only orders delivered between May 10 and August 8, 2026, to the US, UK, Sweden, Colombia, Brazil, Italy and Portugal. Trezor's 90-day retention rule — which it contractually imposes on fulfilment partners — meant older order data had already been deleted or anonymised, capping the blast radius. Affected customers were emailed directly from help@trezor.io; no email means no exposure.

Trezor's guidance is framed around phishing. The address field carries a heavier risk. When roughly 272,000 Ledger customer records leaked in 2020, victims reported ransom demands and threats of violence, not just fake emails. CertiK verified 52 physical attacks on crypto holders in the first half of 2026, up from 39 a year earlier, with home invasions overtaking kidnapping as the most common method.

This is also the second hardware-wallet vendor compromised through a commerce partner this year — Ledger disclosed a January 2026 incident at provider Global-e that exposed names, postal addresses, phone numbers and order details. The attack surface is the supply chain, not the device.

Five of the seven affected countries fall under GDPR or UK GDPR, which requires regulator notification within 72 hours; Brazil's LGPD imposes similar duties.

What Affected Customers Should Do

Treat any unsolicited call, letter or email referencing a Trezor order as hostile. Never type a wallet backup into a website. Verify announcements against trezor.io directly. Consider a mail-forwarding address for future hardware deliveries — Trezor's promised Anonymous Delivery option is not live yet, targeting the EU by September 2026 and the US by year-end.

CVE-2026-63520: SharePoint RCE Patched by Microsoft

protalweb@gmail.com (Vivek Gurung) — Thu, 13 Aug 2026 07:35:54 +0530

Rapid7 and Microsoft have disclosed CVE-2026-63520, a remote code execution flaw in Microsoft SharePoint that completes an unauthenticated exploit chain Rapid7 Labs built for Pwn2Own Berlin. Senior Principal Security Researcher Stephen Fewer found it using an AI agent workflow, and Microsoft shipped the fix in its August 11 update cycle.

CVE-2026-63520 carries a CVSSv3.1 score of 8.1 (High) and is classified as CWE-20: Improper Input Validation. The root cause is an unsafe .NET type instantiation issue in Business Connectivity Services. Code runs with the privileges of the Windows service account behind the SharePoint Site instance. It affects all supported SharePoint versions, plus certain builds of Project Server and Office Web Apps Server.

How the CVE-2026-63520 Exploit Chain Works

On its own, the RCE needs an authenticated session. Paired with CVE-2026-55040 — the JWT token authentication bypass Microsoft patched on July 14 — that requirement disappears. An attacker forges a token, assumes a site user's identity, then crafts a custom .NET gadget chain to run an attacker-controlled OS command.

Rapid7's agent logged 120 hours of runtime across 24 days, 96 sessions, roughly 80,000 tool calls and 256 human prompts to reach a working chain. It is the same category of pre-auth SharePoint chain as ToolShell, which surfaced from Pwn2Own last year.

Which SharePoint Builds Are Fixed

Product	Fixed build	KB
SharePoint Server Subscription Edition	16.0.19725.20522	KB5002893
SharePoint Server 2019	16.0.10417.20198	KB5002894, KB5002896
SharePoint Enterprise Server 2016	16.0.5565.1001	KB5002905, KB5002906

The 30-Day Clock Already Started

Rapid7 will publish full technical details for CVE-2026-63520 within 30 days — roughly September 10. Treat that as a hard deadline, because the first half of this chain just demonstrated the pattern.

Rapid7 released its CVE-2026-55040 write-up and PoC on August 11. Threat intelligence firm Defused reported the next day that its honeypots were recording exploitation attempts using that exact PoC. "Attackers are now using the @rapid7 POC for CVE-2026-55040 against our SharePoint honeypots," Defused stated. Shadowserver still tracks more than 8,500 SharePoint servers exposed online, and neither CVE appears in CISA's Known Exploited Vulnerabilities catalog at the time of writing — though SharePoint flaws have a history of landing there.

Publication to weaponisation took one day. Administrators have until early September before the RCE half gets the same treatment. Both patches, not one.

LiteLLM Breach Exposed 434,000 CI/CD Pipelines, 2,500 Firms

protalweb@gmail.com (Vivek Gurung) — Thu, 13 Aug 2026 07:10:04 +0530

Two threat intelligence firms have published victim data from the March 2026 LiteLLM supply chain attack, and the scale is far beyond anything known when the malicious packages were pulled. CloudSEK counts more than 2,500 potentially exposed organisations and roughly 434,000 CI/CD pipelines, while Hudson Rock says it independently obtained the attackers' raw exfiltration archive and attributed 118,829 CI runner dumps to 2,488 corporate domains.

There is no CVE for this incident because nothing in LiteLLM itself was vulnerable. Attackers linked to the threat group TeamPCP published backdoored LiteLLM 1.82.7 and 1.82.8 to PyPI, where CloudSEK says the packages stayed live for roughly 40 minutes.

Version 1.82.8 shipped a malicious .pth file — a Python startup hook that runs when the interpreter launches rather than when a library is imported — so the payload is executed on every machine where the package was merely installed, sidestepping the --ignore-scripts protection teams rely on to make installs safe.

How Did TeamPCP Get Into LiteLLM?

LiteLLM was never attacked directly. Its CI pipeline installed the Trivy vulnerability scanner unpinned from the system package manager, so when TeamPCP took over Trivy's release process, the poisoned scanner flowed into LiteLLM's build automatically, and that build published the malicious PyPI releases.

The opening was a single automation token that Trivy's maintainers rotated but did not fully revoke. CloudSEK says that left roughly a 20-day window in which the attacker force-pushed malicious code over the scanner's published version tags, meaning downstream builds pulling those tags received attacker-controlled code that still resolved and still looked legitimate. CloudSEK researchers summarised the cascade as "one un-revoked token, three tools deep".

Cyber Kendra covered the original LiteLLM poisoning on March 24, when Endor Labs first identified the malicious versions. The same campaign has since run through Checkmarx's KICS images, the Lightning AI PyPI package, and 42 TanStack npm packages.

What Did the Stealer Take?

On each compromised runner, the payload — tracked by Google as SANDCLOCK — escalated to root and swept SSH keys, AWS, GCP, and Azure credentials, Kubernetes service account tokens, .env files, and CI/CD secrets. CloudSEK reports it scraped secret values directly from /proc/<pid>/mem, including the values GitHub Actions attempts to mask in logs. Cloud keys were read straight from the instance metadata service and Kubernetes tokens from mounted service-account paths, using only the access each runner already carried.

For AI builds specifically, the stealer took LLM API keys and gateway configuration. Screenshots published by Hudson Rock show OpenAI, Anthropic, Gemini, OpenRouter, Fireworks, Groq, and Cerebras keys captured mid-execution — effectively the credentials to an organisation's entire model stack, plus its billing quota.

Collected data was encrypted with AES-256 under a hard-coded RSA-4096 key and shipped to a typosquatted domain. Where exfiltration failed, CloudSEK says the malware created a public repository inside the victim's own GitHub account and uploaded the stolen data there as a release asset, which means some organizations spent months publishing their own secrets without knowing it.

Do the 434,000 and 2,500 Figures Add Up?

The two reports were published a day apart and are being quoted interchangeably, but they do not measure the same things. Laid side by side, the discrepancies matter for anyone trying to size their own exposure.

Figure	Hudson Rock	CloudSEK	Ars Technica
Archive size	153GB RAR	Not stated	195TB
Files in the archive	433,909	Not stated	Not stated
CI/CD pipelines	118,829 attributed runner dumps	~434,000 pipelines	~434,000 pipelines
Organisations	2,488 corporate domains	2,500+ companies	2,500+ organisations
Exposure window	Audit from March 24, 2026	~40 minutes	40 minutes

Two things stand out. First, the headline "434,000 CI/CD pipelines" figure is numerically almost identical to Hudson Rock's count of 433,909 files in the archive. Hudson Rock's own count of CI runner dumps could be attributed to an organisation of 118,829 — about 27 per cent of that total.

The most likely reading is that the circulating pipeline figure counts records or files rather than distinct pipelines, and that roughly three-quarters of the dumps carried no usable organisational marker. Cyber Kendra has not independently verified either dataset, and neither firm has published a methodology reconciling the two counts.

Second, the archive size differs by roughly three orders of magnitude between Hudson Rock's own write-up (153GB) and Ars Technica's account of it (195TB). We have not been able to establish which is correct.

None of this makes the incident smaller. CloudSEK is explicit that its numbers describe reconstructed exposure and should not be read as proof that every listed organization was compromised. But a defender sizing their own blast radius should treat 434,000 as a count of leaked records, not as a count of breached pipelines, until either firm says otherwise.

Which Companies Are Affected?

CloudSEK's high-confidence list runs to dozens of names across technology, defence, banking, telecoms, manufacturing and logistics. It includes NVIDIA, Amazon Web Services, Samsung Electronics, Cisco Systems, Salesforce, ServiceNow, Siemens AG, S&P Global, Airbus U.S. Space & Defense, John Deere, Regeneron, London Stock Exchange Group, Thomson Reuters, FedEx, Munich Re, MediaTek, Volkswagen, Deloitte, Kroger, Thales, X Corp, Zscaler, Epic Games, Orange, HP, Philips, Vodafone, Carl Zeiss, Deutsche Bahn, NGINX, BT Group, Liebherr, Krungthai Bank and Roku.

The per-organisation counts are uneven in ways worth reading closely. X Corp shows 3,459 secrets across 1,153 runs. Orange shows 180 secrets but 5,642 runs. Volkswagen shows 2,242 runs and zero secrets. A high run count with no secrets suggests pipelines that executed the package without holding credentials the stealer could reach; a high secret count on a few runs suggests the opposite.

Attribution is also harder than the domain column implies. Hudson Rock describes one case where the committer email belonged to @siriusxm.com, but the environment dump's self-hosted GitLab and registry endpoints placed the breach inside AdsWizz, a SiriusXM subsidiary. Routing an alert to the wrong SOC on the strength of an email domain wastes the window that matters.

Hudson Rock's larger concern is the files with no marker at all. Many pipelines are configured generically, and the firm says those dumps hold "active database passwords, third-party API keys, and cloud credentials" with nothing tying them to a company. Absence from both firms' lists is not evidence of safety.

Are the Stolen Credentials Still Valid?

In at least one case, yes. After the Ars Technica report went live, Kevin Beaumont said a major US technology company told him it had rotated everything and the disclosure was a non-event. Its responsible disclosure policy permitted credential testing, so he tested them. "Almost every one worked," he wrote and filed a report.

That is the finding defenders should carry out of this story. These credentials date from March. Five months of assumed rotation did not close the exposure at one of the largest technology companies in the United States, which tracks with the FBI's July FLASH advisory (FLASH-20260702-01) warning that affiliated actors are likely to weaponise the harvested credentials long after the original intrusion.

What Should You Do If You Ran LiteLLM 1.82.7 or 1.82.8?

Rotate broadly, not narrowly. Rotating the LiteLLM or model-provider key alone is insufficient. Any credential readable by the affected process — in environment variables, process memory, on disk, injected into the job, or retrievable through an instance metadata service — should be treated as exposed until validated. That includes AWS, GCP and Azure IAM keys, Kubernetes service account tokens, and GitHub and GitLab personal access tokens.
Search build history, not just current lockfiles. Scheduled jobs, dependency resolvers, ephemeral runners, developer laptops and cached container layers can all hold the artifact long after PyPI removed it. Version 1.82.6 is the last confirmed clean release.
Hunt for persistence. Check site-packages for unauthorised .pth files and look for a systemd unit masquerading as a "System Telemetry Service". CloudSEK is also named tpcp-docs/docs-tpcp as a repository pattern worth hunting for.
Check your own GitHub org for repositories you did not create. The exfiltration fallback published stolen data as a release asset in the victim's account.
Pull logs from March 24, 2026, onward. Review CloudTrail, Kubernetes API audits, source control, package registry and cluster logs for token use from unfamiliar IPs, geographies, runners or user agents.
Check the exposure portals. Both firms have published domain lookup tools, including CloudSEK's. Note that both are gated behind vendor sign-up flows.

The structural lesson is the one Alon Gal, Hudson Rock's co-founder and CTO, put to Ars Technica: a single upstream breach now reaches thousands of companies at once, and a 40-minute dependency window produced hundreds of thousands of harvested environments. TeamPCP has since open-sourced the Shai-Hulud framework used across this campaign, which means the next actor to run this playbook will not need to build any of it.

Pirates Bay Proxy List August 2026: Unblock Pirate Bay

protalweb@gmail.com (Vivek Gurung) — Mon, 12 Dec 2022 23:21:00 +0530

The Pirate Bay (TPB) is one of the oldest and most popular torrent websites, allowing users to share and download torrent files for movies, TV shows, music, games, and software. However, due to legal pressure, many countries have blocked access to the original Pirate Bay.

Despite these blocks, people still try to access The Pirate Bay using shared proxy servers. If you're struggling to access The Pirate Bay due to regional restrictions, this guide will walk you through the best Pirate Bay proxy sites, how they work, and safer alternatives to keep you downloading without hassle.

If you're wondering how to unblock The Pirate Bay, this guide covers everything you need to know, including:

✅ Pirate Bay proxy list (April 2026)
✅ How proxy sites work
✅ Is torrenting legal?
✅ Why is Pirate Bay blocked?
✅ Best VPNs for Pirate Bay
✅ Tor Browser vs. VPN for torrenting
✅ Safe alternatives to Pirate Bay

By the end, you’ll know how to access The Pirate Bay safely and legally.

What Is The Pirate Bay?

The Pirate Bay was launched in 2003 by the founders of the Swedish group advocating for free file sharing. It quickly became the go-to torrent site for millions, despite legal battles and attempts to shut it down.

Why Is Pirate Bay So Popular?

✔ Huge database of movies, music, games, and software
✔ Magnet links for faster downloads
✔ No registration required
✔ Active community of uploaders

However, because it hosts copyrighted content, many ISPs and governments have blocked it.

What Is a Pirate Bay Proxy or Mirror Site?

A Pirate Bay proxy (or mirror site) acts as a gateway to the original Pirate Bay when the main site is blocked. These proxy servers reroute your connection, making it appear as though you're accessing the site from a different location where restrictions don’t apply.

How Does a Pirate Bay Proxy Work?

When you visit a proxy site, your request is sent to an intermediary server.
This server forwards your request to The Pirate Bay and sends the data back to you.
Your real IP address stays hidden, helping you bypass ISP or government blocks.

This method is one of the easiest ways to unblock The Pirate Bay, but it comes with risks—more on that later.

Why Is Pirate Bay Blocked in Many Countries?

Governments and copyright agencies have pressured ISPs to block Pirate Bay’s site due to:

Copyright infringement – Hosting pirated movies, music, and software is illegal.
Legal pressure from Hollywood & record labels – Companies like Disney and Warner Bros. push for bans.
Anti-piracy laws – Countries like the US, UK, Australia, and India enforce strict blocking.

Despite blocks, users still access The Pirate Bay using proxy sites, VPNs, or Tor.

Is Torrenting Legal?

Torrenting itself is legal, but downloading copyrighted content without permission is illegal in most countries.

Legal Uses of Torrenting:

✅ Linux distributions (Ubuntu, Fedora, Kali Linux, etc.)

✅ Public domain movies & books

✅ Independent artists sharing free music

Illegal Uses of Torrenting:

❌ Downloading the latest Marvel movie

❌ Sharing paid software (Windows, Photoshop)

❌ Distributing copyrighted music albums

Penalties for illegal torrenting:

Fines (up to thousands of dollars)
ISP warnings or throttling
Legal action in severe cases

How Does a Pirate Bay Proxy Work?

A Pirate Bay proxy acts as a middleman between you and the real Pirate Bay site.

Step-by-Step Process:

1️⃣ You visit a proxy site (e.g., piratebay.proxy)
2️⃣ The proxy fetches data from The Pirate Bay’s servers
3️⃣ It sends the data back to you, bypassing ISP blocks

Pros of Using Proxies:

✔ Bypasses government/ISP blocks
✔ No software installation needed
✔ Works instantly

Cons of Using Proxies:

❌ No encryption (your ISP can still see your activity)
❌ Some proxies contain malware or ads
❌ Unreliable (many proxies shut down quickly)

Pirate Bay Proxy List (2026) – Working Sites

Here’s an updated list of working Pirate Bay proxy sites:

Proxy Site	Status	Speed
piratebay.party	✅ Working	⚡ Fast
thepiratebay10.infoy	✅ Working	⚡ Fast
tpb.party	✅ Working	⚡ Fast
thepiratebay.party	✅ Working	⚡ Fast
piratebay.party	✅ Working	⚡ Fast
thepiratebay.part	✅ Working	🐢 Slow
thepiratebay7.com	✅ Working	⚡ Fast
thepiratebay0.org	✅ Working	🐢 Slow
pirateproxylive.org	✅ Working	⚡ Fast
thepiratebay.cloud	✅ Working	🐢 Slow

Note: Proxy sites change frequently—if one doesn’t work, try another.

Is Using a Pirate Bay Proxy Safe?

Proxies help access Pirate Bay, but they don’t make torrenting safe.

Risks of Using Pirate Bay Proxies:

🔴 Malware & fake torrents – Some proxies inject ads or distribute infected files.
🔴 No encryption – Your ISP can still track your downloads.
🔴 Legal risks – Copyright trolls monitor torrent traffic.

How to Stay Safe?

✔ Use a VPN (recommended) – Hides your public IP address and encrypts traffic.
✔ Check comments & seeders – Avoid torrents with no reviews.
✔ Use antivirus software – Scan downloaded files before opening.

How to Download Torrents Using a Pirate Bay Proxy

Step 1: Find a Working Proxy

Use the Pirate Bay proxy list above. If one doesn’t work, try another from the list, as the domain frequently changes.

Step 2: Search for Torrents

Type the movie/game name in the search bar.
Filter by seeders (high = faster download).

Step 3: Download the Torrent

Click "Get This Torrent" (magnet link) or download the .torrent file.
Open it in qBittorrent or uTorrent.

Step 4: Stay Anonymous (Use VPN)

A VPN like NordVPN or ExpressVPN hides your IP.

Why Use a VPN for Pirate Bay?

Since proxy sites don’t encrypt traffic, a VPN is the safest way to torrent.

Best VPNs for Pirate Bay (2026)

VPN	Speed	No-Logs Policy	Price
NordVPN	⚡ Fast	✅ Yes	$3.29/mo
ExpressVPN	⚡ Fast	✅ Yes	$6.67/mo
Surfshark	⚡ Fast	✅ Yes	$2.49/mo

Why a VPN is Better Than a Proxy:

✔ Encrypts all traffic (ISP can’t see what you download)
✔ Changes your IP address (hides your real location)
✔ Works with all torrent sites (not just Pirate Bay)

Can You Use Tor Browser to Unblock Pirate Bay?

Yes, but Tor is slow for torrenting.

Pros of Tor for Pirate Bay:

✔ Extreme anonymity (hard to trace)
✔ Bypasses censorship

Cons of Tor for Torrenting:

❌ Very slow downloads (Tor wasn’t made for P2P)
❌ Some exit nodes block torrent traffic

Best for: Checking Pirate Bay, not downloading large files.

The Pirate Bay Alternatives (2026)

If proxies aren’t reliable, consider these websites like The Pirate Bay:

Site	Best For	Key Feature
RARBG	High-quality torrents	Verified uploads, minimal fake files
1337x	User-friendly interface	Active community, organised categories
KickAss Torrents	Wide variety of content	Frequently updated domains
YTS	HD movies	Small file sizes, high-quality rips
Torrentz2	Meta-search engine	Searches multiple torrent sites at once

Conclusion: Should You Use Pirate Bay Proxies?

✅ Yes, if you need quick access, Proxies help bypass blocks.
❌ No, if you want safety, use a VPN instead.

Final Tips:

🔹 Always use a VPN for torrenting
🔹 Avoid downloading copyrighted material illegally
🔹 Try alternatives like ExtraTorrents if the Pirate Bay is down

Now you know how to unblock The Pirate Bay safely. Happy (and legal) downloading! 🚀

FAQ Section

Q: Where are Pirate Bay servers located?

A: Pirate Bay frequently changes hosting locations (often in countries with lax copyright laws).

Q: Can I create my own proxy site?

A: Yes, but running a Pirate Bay proxy can lead to legal trouble.

Q: Why do some Pirate Bay proxies stop working?

A: They get taken down due to copyright complaints.

Q: Is Pirate Bay shutting down?

A: No, but it frequently changes domains to avoid blocks.

Q: What’s the safest way to use Pirate Bay?

A: VPN + trusted proxy + antivirus is the best combo.

Q: How do I find a working proxy?

A: The list above is updated, but if a proxy fails, search for "Pirate Bay proxy lists".

Need more options? Explore alternative torrent sites like ExtraTorrents or RARBG 📌 for a smoother experience. Happy (and safe) downloading! 🚀

YIFY Proxy List (YTS) August 2026- Working Updated

protalweb@gmail.com (Vivek Gurung) — Sun, 29 Jan 2023 09:33:00 +0530

Yify, also known as YTS, was a popular website for downloading and streaming movie torrents. The site was known for its high-quality movie releases and its user-friendly interface, which made it a favorite among many movie enthusiasts. Unfortunately, the original Yify site was shut down in 2015 due to copyright infringement issues.

However, the YTS brand has been taken over by a new group that continues to provide high-quality movie releases on the YTS website. The new YTS site operates similarly to the original, offering a wide selection of movies for download and streaming, along with a user-friendly interface and a clean, easy-to-navigate design.

One of the biggest draws of the new YTS site is its commitment to releasing only high-quality movies. The site only releases movies in 720p and 1080p resolution, ensuring that users can enjoy the best possible viewing experience. Additionally, the site provides a wide range of subtitles in various languages, making it accessible to a global audience.

Another great feature of the new YTS site is its user-friendly interface. The site's simple and clean design makes it easy to find the movies you're looking for, and the site's powerful search function allows you to quickly find the movies you want. Additionally, the site offers a variety of sorting options, including genre, release date, and rating, making it easy to find the perfect movie for any occasion.

Warning! Cyber Kendra does not condone the use of torrents to illegally obtain content. Using the following torrent websites for illegal purposes is done entirely at your own risk.
Cyber Kendra takes no responsibility for any legal problems you encounter

It is always important to keep in mind that downloading copyrighted content is illegal in many countries, and it's important to use such sites with caution. It's always recommended to use a VPN service to protect your privacy and to stream content legally instead of downloading copyrighted content.

Live Proxy sites of Yify or YTS Proxy

Have a look at the best YIFY Proxy list sites that can help download YIFY torrents. All the URLs are sourced from different parts of the Internet and are found to be working.

You can unblock YIFY domains and mirror sites from anywhere in the world. We check the proxy links every week to ensure they are working properly.

yts.gs
yts.torrentworld.pw
ytss.unblocked.lol
yts.mrunlock.xyz
yts.homes
yts.mx NEW
yts.rs NEW

Yify Proxy: What it is and How to Use it

Yify is a popular torrent website that is known for its vast collection of movies and TV shows. However, due to copyright infringement issues, the website has been blocked in many countries. This is where the Yify proxy comes in. A Yify proxy is a mirror website that provides access to the original Yify website, allowing users to download movies and TV shows even when the original site is blocked.

Benefits of Using Yify Proxy

Access to a vast collection of movies and TV shows: Yify Proxy provides access to the original Yify website, which offers a wide selection. This means that users can download their favorite movies and TV shows without any restrictions.

Cost-effective: Yify proxy is a free service, which means that users do not have to pay any subscription fee or monthly charges to access the website.

Anonymous Browsing: Yify proxy allows users to browse the website anonymously, which means that their IP address and other personal information are not tracked. This is especially useful for users who live in countries where the website is blocked.

Easy to use: Yify proxy is very easy to use and requires no technical skills. Users can simply type in the URL of the Yify proxy website and start downloading movies and TV shows.

Cyber Kendra does not condone the use of torrents to illegally obtain content. Using the following torrent websites for illegal purposes is done entirely at your own risk.
Cyber Kendra takes no responsibility for any legal problems you encounter.

Alternatives to Yify Proxy

KickAss Proxy List: KickAss or KatCr is a popular torrent website with a wide variety of content, including movies, TV shows, games, and software. It is also a free service and has a user-friendly interface.

RARBG: Another popular torrent website with a vast collection of movies and TV shows. It is also a free service and has a user-friendly interface.

1337x proxy: 1337x is a popular torrent website that has a wide variety of content, including movies, TV shows, games, and software. It is also a free service and has a user-friendly interface.

LimeTorrents: a popular torrent website offering a wide variety of content, including movies, TV shows, games, and software. It is also a free service and has a user-friendly interface.

The Pirate Bay: The Pirate Bay is one of the oldest and most popular torrent websites. It has a vast collection of movies, TV shows, games, and software. It is also a free service and has a user-friendly interface.

Conclusion

Yify Proxy is a great way to access the original Yify website and download movies and TV shows. However, users should be aware that downloading copyrighted content without permission is illegal in many countries. Therefore, it is important to use a VPN to protect your privacy and stay anonymous while browsing Yify proxy or any other torrent website.

ExtraTorrents Proxy List 2026 [August] To Unblock Extra torrent

protalweb@gmail.com (Vivek Gurung) — Thu, 19 Oct 2023 22:36:00 +0530

ExtraTorrents was one of the most popular torrent sites on the web, providing access to millions of torrent files for movies, TV shows, music, games, software, and more.

Undoubtedly, it was one of the most popular torrent websites before it was shut down in 2017. However, in May 2017, ExtraTorrents went offline permanently after an alleged domain seizure.

Millions of users download movies, games, music, software, and more on ExtraTorrents each day.

When ExtraTorrents went offline permanently, many users began searching for proxy sites to access the platform again. While ExtraTorrents is gone, proxies offer a workaround to access the site via mirrors and caches.

How Does ExtraTorrent Proxy Work To Unblock ExtraTorrents?

Like other torrenting websites (The Pirate Bay, KickAss Torrents, YIFY, etc.), ExtraTorrents also has its own mirrors or proxies.

An ExtraTorrents proxy site acts as an intermediary between you and ExtraTorrents. When you access an ExtraTorrents proxy, the proxy website connects to servers and databases where ExtraTorrents data is stored.

It then fetches the pages, torrent files, and other content you request and displays them to you. This allows access to ExtraTorrents even though the original site is inaccessible.

The proxy also masks your IP address, hiding your identity and location. This allows access if ExtraTorrents is blocked by your ISP or country. Overall, proxies provide a clever workaround to use ExtraTorrents again through cached copies.

Benefits of Using an ExtraTorrents Proxy

There are a few key benefits to accessing ExtraTorrents through a proxy site:

Access cached copies of ExtraTorrents content: Even though ExtraTorrents is down, proxy sites can still provide access to cached copies of site pages and torrent files. This allows you to browse and download content just like when ExtraTorrents was still up.
Bypass ISP blocks: In some locations, internet service providers block access to torrent sites like ExtraTorrents. Proxies can bypass these blocks, allowing access from restricted networks.
Enhanced privacy: Using a proxy hides your IP address and location, providing greater anonymity. This prevents sites like ExtraTorrents from tracking your downloads.
Circumvent country restrictions: allows access to ExtraTorrents from restricted regions.
Nostalgia - Long-time users still navigate the familiar ExtraTorrents interface through proxies.

Cyber Kendra does not condone the use of torrents to illegally obtain content. Using the following torrent websites for illegal purposes is done entirely at your own risk. Cyber Kendra takes no responsibility for any legal problems you encounter

Risks of ExtraTorrents Proxies

While proxies provide useful access to blocked sites, there are also some risks to consider:

No guarantees torrents are safe: ExtraTorrents proxies lead to cached copies of site content. However, there's no guarantee that these torrent files are malware-free and safe to download. Be cautious.
Possibility of outdated content: Proxy sites only have access to cached copies of ExtraTorrents. This content may be outdated, with broken torrents and missing files. The original ExtraTorrents library can't be recreated.
Proxies come and go: Proxy sites are inherently unstable and can go down or change URLs at any time. A proxy that works one day may be inaccessible the next.
Legality is questionable: accessing copyright-infringing torrents via proxies falls into a legal grey area. While proxies themselves aren't illegal, they enable piracy, which may carry risks.

Latest ExtraTorrents Proxy Sites

Several ExtraTorrent proxy and mirror sites appeared after the original site went down. Here are some of the most popular and reliable options in 2026:

ExtraTorrents Proxy 1
ExtraTorrents Proxy 2
ExtraTorrents Proxy 3
ExtraTorrents Proxy 4
ExtraTorrents Proxy 5
ExtraTorrents Proxy 6
ExtraTorrents Proxy 7
ExtraTorrents Proxy 8

ExtraTorrents Alternatives

While proxies provide access, no ExtraTorrents mirror is an exact replacement. Here are some top alternatives for torrent downloads:

The Pirate Bay - One of the most well-known torrent sites globally, with a huge selection.
RARBG - Popular site with a clean interface, good for movies and TV.
1337X proxy - Extensive torrent database for all types of media.
KickAss (KATcr) -
YTS - Great source focused on movie torrents in a range of qualities.
Torlock - A Torrent index with a strong verified uploader community.

These alternatives help fill the void left by ExtraTorrents. However, proxies remain useful to access ET's extensive library.

VPN To Unblock ExtraTorrents Site

A VPN, or virtual private network, provides another option to access blocked sites like ExtraTorrents. A VPN routes your traffic through an encrypted tunnel to a server in another location.

This hides your true IP address and spoofs your location. Use a VPN to:

Bypass geographic blocks and access ExtraTorrents from anywhere.
Encrypt traffic so ISPs can't see your activity.
Hide torrenting from your ISP and copyright enforcers.
Improve security when downloading files.

Top VPNs like ExpressVPN and NordVPN work seamlessly for torrenting.

How To Download Torrent Files?

Here is a quick guide to downloading torrents safely:

Cyber Kendra does not condone the use of torrents to illegally obtain content. Using the following torrent websites for illegal purposes is done entirely at your own risk. Cyber Kendra takes no responsibility for any legal problems you encounter

Choose a trusted proxy or VPN for security.
Find a torrent file for the content you want to download. Note: Stick with trusted uploaders.
Download the small .torrent file onto your computer, or you can also get/copy the magnet link of the torrent.
Open the torrent in a BitTorrent client like qBittorrent or uTorrent.
Select the location where you want to save the full content files. Let the download start!
It is always recommended to do a Virus scan before opening. For this, you can use the VirusTotal website, which is very much trusted to check the files shared on the internet.

Is Torrenting Legal?

The legality of torrenting depends on usage:

Downloading copyrighted material is often illegal without permission. This includes movies, TV shows, games, music, and software.
Torrenting the public domain and authorised content is perfectly legal. Legally available games, movies, and files can be torrented safely.
Many jurisdictions turn a blind eye to individual torrent downloads for personal use only. But uploading/sharing may cross the line.
Use common sense and torrent responsibly! A VPN or proxy provides extra anonymity for those who sail the high seas.

What Happened To ExtraTorrents?

ExtraTorrents grew into one of the top torrent communities in the 2000s. However, in May 2017, the site suddenly went offline.

Speculation points to legal pressure around copyright. Some reports suggest its domain was seized through legal channels.

Whatever the cause, ExtraTorrents remains inactive with no plans to return. The admins did not set up redirects or alternatives before the shutdown.

While the original community is gone, ExtraTorrent's legacy lives on through proxies and replacements. But the loss left a mark on the torrent landscape.

In summary, while ExtraTorrents is gone, various proxy sites provide roundabout access to cached copies in 2023. However, use caution and protect yourself when accessing any torrent platform.

1337x Proxy List 2026 [August 2026] - Best Alternative and Mirror

protalweb@gmail.com (Vivek Gurung) — Sun, 7 Apr 2024 23:21:00 +0530

In the ever-evolving world of torrenting, 1337x remains one of the most popular platforms for downloading movies, TV shows, games, and more. However, due to regional restrictions and privacy concerns, many users rely on 1337x proxy sites and mirrors to access this popular torrent platform.

This guide will walk you through everything you need to know about 1337x proxies and mirrors, including how to unblock 1337x proxies, ensure safe torrenting, and explore the best alternatives.

What Is a 1337x Proxy?

A 1337x proxy acts as a middleman between your device and the main 1337x torrent sites. When you use a proxy, your internet traffic is routed through another server, hiding your real IP address and location. This helps you:

Bypass ISP blocks (if your ISP blocks access to torrent sites).
Maintain privacy while torrenting files.
Access 1337x unblocked even if the main domain is restricted.

However, not all proxies are safe—some may be slow, unreliable, or even malicious. Always choose trusted 1337x proxy sites to avoid security risks.

Are 1337x Proxies Legal and Safe?

Legality

Using a torrent proxy itself isn’t illegal, but downloading copyrighted content without permission violates laws in many countries. Always check the legal status of files before downloading.

Safety Concerns

Free proxies may log your data or contain malware.
Reputable proxies use encryption to protect your activity.
For maximum security, consider a VPN (Virtual Private Network) instead, as it provides stronger encryption and greater anonymity.

Top Working 1337x Proxy Sites (2026)

Here’s a verified list of 1337x mirrors that are currently active:

1337x.bz
www.1337x.tw
1337x.proxyninja.org
ww3.13377x.tw
1337x.to
1337x.st
1337x.pro
x1337x.eu
x1337x.ws

(Note: Proxy sites can change frequently. Always check for the latest updates.)

Best Alternatives to 1337x (2026)

If 1337x torrent sites are down, try these websites like 1337x:

The Pirate Bay Proxy – One of the oldest torrent download sites, offering movies, games, and software.
RARBG Proxy – Known for high-quality movies & TV shows.
YTS Proxy – Specialises in HD films with small file sizes.
Zoogle Proxy – A growing peer-to-peer community with a vast library.
Kickass Torrents Proxy – Despite past legal issues, it remains a popular torrenting method.

How to Use a 1337x Proxy

Using a 1337x mirror site is simple:

Find a working proxy (use the list above or search for updated ones).
Enter the URL (e.g., https://1337x.bz) in your browser.
Browse and download torrents as usual.

For extra security:

Use a VPN to hide your IP.
Avoid clicking on suspicious ads.

How to Unblock 1337x If It’s Restricted

If your ISP is blocking access to torrent sites, try these methods:

✅ Use a VPN – Connects you to a server where 1337x is accessible.
✅ Try Different Mirrors – Search for new 1337x proxy sites.
✅ Use Tor Browser – Accesses the site anonymously via the Tor network.

Staying Safe While Torrenting

Avoid downloading copyrighted material illegally.
Use a VPN for encrypted browsing.
Stick to trusted proxies to prevent malware risks.

Final Thoughts

1337x proxies and mirrors are useful for bypassing restrictions, but always prioritise safety. Whether you're looking to download free content or explore popular torrent sites, using a VPN and verified proxies ensures a smooth and secure experience.

Stay updated with the latest 1337x unblocked links, and happy torrenting! 🚀

Disclaimer: This guide is for educational purposes only. We do not endorse illegal downloading. Always comply with your local laws when using torrent websites.

TorrentGalaxy Proxy List 2026 : Best Alternative of TorrentGalaxy [August Update]

protalweb@gmail.com (Vivek Gurung) — Fri, 30 May 2025 22:56:00 +0530

Are you looking for the best TorrentGalaxy proxy list, mirror sites, and alternatives, or a new torrent site to download your favourite movies, TV shows, games, or software?

So you are in the right place for your needs.

TorrentGalaxy mysteriously disappeared overnight, with just a single line message in June 2024, which left many users puzzled and concerned about its future. Torrent Galaxy often faces downtime or domain changes due to legal pressures, and many users are seeking reliable alternatives.

Here's a detailed guide to help you navigate the best options in 2026, ensuring you find the platform that best matches your torrenting needs.

Why Look for Alternatives?

Before diving into the alternatives, let's briefly discuss why one might need to look beyond Torrent Galaxy:

Legal Issues: Torrent sites frequently face legal actions, which can lead to site closures or domain shifts.
Site Reliability: Downtime or slow loading times can significantly inconvenience users.
Content Availability: Different sites might offer better access to certain types of content or a more extensive library in specific areas, such as anime or indie games.
User Experience: Not all torrent sites are created equal when it comes to user interface, speed, and community engagement.

Cyber Kendra does not condone the use of torrents to illegally obtain content. Using the following torrent websites for illegal purposes is done entirely at your own risk. Cyber Kendra takes no responsibility for any legal problems you encounter

TorrentGalaxy Proxy list for 2026

https://torrentgalaxy.to
https://torrentgalaxy.hair
https://torrentgalaxy.one
https://torrentgalaxy.skin
https://torrentgalaxy.mx
https://tgx.rs

TorrentGalaxy Proxy Onion Domain

You can use the TorrentGalaxy proxy from the .onion address. Open it in the Tor browser to unblock the TorrentGalaxy torrent site, bypassing the ISP firewall, and, for enhanced privacy and stability, consider using residential proxies alongside Tor.

galaxy3yrfbwlwo72q3v2wlyjinqr2vejgpkxb22ll5pcpuaxlnqjiid.onion
http://galaxy3k5w5zd77zz2fzrrplj4hkcn6dbauy3nyrxjnhaszgc3xyhrqd.onion (Tor proxy)

Now, let's explore some of the top alternatives to TorrentGalaxy :

1. 1337x

1337x has established itself as a robust torrent site with a wide range of content from movies to music, software, and games. Known for its stability, 1337x has avoided many of the pitfalls other sites fall into.

Key Features:

User-Friendly Interface: Clean and straightforward layout.
Verified Torrents: Many torrents are user-verified, reducing the risk of downloading malicious files.
Active Community: Comment sections often provide useful insights or warnings about torrent quality.

For Users: If you're looking for a site with a broad library and good community feedback, 1337x is ideal. However, always use a VPN for safety, given its notoriety.

2. YTS

While YTS primarily focuses on movies, it's renowned for its high-quality video torrents that are small in file size, making it excellent for those with limited bandwidth or storage. Check the YTS proxy list.

Key Features:

Quality Torrents: High-quality rips with surprisingly small sizes.
Simplistic Design: Makes navigation easy for any user.

For Users: Movie buffs will appreciate YTS's focus and efficiency, though it lacks variety in other content types, such as TV shows or software.

3. EZTV

EZTV is your go-to if TV shows are what you’re after. It's been around for a long time, known for its reliability and extensive collection of TV series.

Key Features:

TV Show Specialisation: Probably the best place for TV content.
Immediate Availability: Episodes often appear shortly after airing.

For Users: If your torrenting needs are predominantly television-related, EZTV is unparalleled.

4. NYAA

NYAA specialises in East Asian media, particularly anime, manga, and Japanese video games. It's a revival of the original NYAA, which was shut down due to legal issues.

Key Features:

Anime Haven: Extensive collection of anime and manga.
Quality Control: Although not all torrents are verified, the community's feedback system helps sort the good from the bad.

For Users: Anime and manga enthusiasts will find NYAA a treasure trove, but it might not satisfy those looking for Western media.

5. RARBG

RARBG has a reputation for high-quality torrents across various categories. It's known for its movie torrents and provides good music, software, and game options.

Key Features:

High-Quality Torrents: Often provides remuxes or high-bitrate versions of movies.
Community Voting: Allows users to vote on torrent quality.

For Users: Ideal for users who prioritise quality over quantity. Its domain has been seized multiple times, so staying updated via social media or forums can help.

6. Heliosphere

Mentioned as a favoured alternative in some social media posts, Heliosphere is less well-known but is gaining traction, especially among those seeking a fresh take on torrent communities.

Key Features:

Growing Library: While not as extensive, it's curated well.
User Interface: Modern and easy to navigate.

For Users: This is a good option if you're looking for a site with fewer ads and less legal heat.

7. Stremio with Torrentio Add-on

While not a traditional torrent site, Stremio, with the Torrentio add-on, provides a streaming-like experience from torrents, offering content in a more user-friendly format.

Key Features:

Integration with Torrent Sources: Pulls from various torrent sites.
Streaming: Watch content without downloading directly from torrent sources.

For Users: Perfect for those who prefer streaming over downloading. You still need a VPN for privacy.

Cyber Kendra does not condone the use of torrents to illegally obtain content. Using the following torrent websites for illegal purposes is done entirely at your own risk. Cyber Kendra takes no responsibility for any legal problems you encounter

Tips for Safe Torrenting

Use a VPN: Always torrent with one to mask your IP address and keep your activities private.
Check Comments: Review user comments before downloading to gauge torrent reliability.
Antivirus: Keep your antivirus software up to date to scan torrent files for malware.
Legal Awareness: Understand the copyright laws in your region. Torrenting copyrighted material without permission is illegal in many countries.

Conclusion

Finding a good alternative to Torrent Galaxy isn't just about replacing one site with another; it's about choosing a platform that aligns with your specific needs—content focus, user experience, or security features.

Each site listed here offers unique strengths, from YTS's compact movie files to EZTV's extensive TV show archive. When switching, consider what you value most in your torrenting experience and choose accordingly.

Remember, the landscape of torrent sites is ever-changing, so staying informed through tech blogs, forums, and social media can keep you ahead of the curve.

Happy torrenting, and always stay safe online!

Blogger Malware Lockout: What Happened and What to Do

protalweb@gmail.com (Vivek Gurung) — Wed, 5 Aug 2026 23:42:30 +0530

✅ RESOLVED — Updated August 12, 2026
Google has fixed the bug behind the August 4 mass lockout, and Blogger Product Experts have confirmed the root cause is resolved. Most blogs were back within 24 to 48 hours.
You can edit your theme again. The advice to freeze your template applied during the incident and has now been formally lifted. If your blog is still locked, request a review — blogs that never appealed may not be in the review queue at all.

What follows is the full record: what happened, why restored blogs kept getting locked a second time, and how to make sure a platform-side classifier can never take your archive offline again.

The resolution: what Google and the Product Experts confirmed

On August 9, a Blogger Gold Product Expert posted that the issue had been resolved and that confirmation had come from the team responsible, pointing to an official announcement published in the Spanish-language Blogger community. The thread's original poster, a Diamond Product Expert, followed with a summary that is now the marked Recommended Answer:

The root cause has been resolved. Most blogs were back online within the first 24 to 48 hours. Blogs still locked should click Request review in the dashboard, or wait if they have already done so. Not all reports are false positives, and each case is reviewed individually.
— Blogger Diamond Product Expert, August 9, 2026

Three details in that summary matter more than the headline.

Editing your theme is safe again. The same summary states that anyone whose blog was reinstated, or never affected, can return to normal — publishing posts and editing themes included. During the incident the pinned advisory had been amended to tell users to temporarily hold off on theme and layout edits, explicitly on the basis of community reports. That caution is now withdrawn.

Not every locked blog was a false positive. This is the line most coverage has skipped. The Product Expert states plainly that each case is reviewed individually and that not all reports in the thread were misclassifications. A blog still locked after the fix is not automatically owed a restoration.

If you never appealed, appeal now. A second Diamond Product Expert noted that the official announcement suggests only blogs that requested a review will be reviewed. There is some ambiguity in the wording, and the safe reading is the cautious one: an un-appealed blog may simply be sitting outside the queue.

The support thread has since been soft locked, with only Product Experts and the original poster able to reply. It finished with 531 "I have the same question" votes.

What happened on August 4

The finding that mattered most during the incident sat buried 140 comments deep in Google's own support thread: restored blogs were being locked again within minutes, and the common thread in almost every re-lock was a write to the template — not a new post. Here is the full record.

The first wave

On August 4, 2026, Google's automated systems began locking Blogger blogs en masse, citing the Malware and Similar Malicious Content policy. Owners received an email saying their blog had been removed. The dashboard showed a red padlock and a notice that the blog was removed for violating Blogger's Community Guidelines.

The first wave hit around 2:15 PM Eastern on August 4. Reports followed in sequence around the world: Brazil at roughly 2:30 PM local, France and Italy through the evening, Korea at about 2:00–2:15 AM KST on August 5, then India, Indonesia, Vietnam and the Gulf through the morning.

A Blogger Diamond Product Expert posting as WebLove.PL opened a tracking thread and stated plainly that the volume of identical reports pointed to misclassification by automated systems, adding that false positives happen, but not at this scale. The Blogger engineering team was notified.

That thread went on to draw over 170 replies and more than 500 "I have the same question" votes. For roughly the first day it was the only acknowledgement of any kind — Google published nothing on its blog, its status dashboard or its social channels before issuing a brief statement to BleepingComputer on August 5, confirming a bug had incorrectly flagged Blogger-hosted sites and saying a fix was in progress. No postmortem, affected-blog count, or technical explanation has been published since.

The scale is not normal

Counting distinct blogs named in the thread and adjacent threads gives a partial list running well past a hundred, across at least sixteen languages — English, Korean, Arabic, Portuguese, Spanish, French, German, Italian, Greek, Indonesian, Thai, Vietnamese, Romanian, Dutch, Polish and Hindi.

The affected sites have nothing in common except the platform:

whomyouknow.com — 31,200+ posts, offline about 20 hours
dynamictutorialsandservices.org — an educational site running since 2008, 4,600+ pages
raidersofthelostscent.blog — vintage perfume archive, active since 2009, 3M+ pageviews
tknt-hsu.blogspot.com — the official academic blog of the Faculty of Design and Art, Hoa Sen University, Vietnam
mediablog.ro — a Romanian journalism site of more than 15 years
spata-artemis.com — a Greek local news archive
One Arabic blogger reported four blogs and over 10,000 posts locked at once
A Korean blogger reported that six blogs were suspended simultaneously
One user reported 20 million lifetime views on a purely educational blog

Also caught: an 18-year-old Spanish maths blog, a 14-year-old quilting blog, a devotional lyrics site, a dog care blog in Hinglish, a Lombardy events calendar, a baseball news site, and — as one user noted with some irony — an account suspended for "spam" whose only post was pictures of a kitten.

One report deserves particular weight. A blogger running three separate blogs on three different Google accounts watched all three lock inside a fifteen-minute window. They decompiled and pretty-printed the minified JavaScript in their theme files, checked for redirects and hidden iframes, and ran multi-engine analysis through VirusTotal plus a sandbox behavioural report. Zero detections across every engine. Search Console is clean on all three properties.

That is about as close to a controlled experiment as a support forum ever produces, and it points squarely at the classifier rather than the content.

The re-lock loop: why restored blogs went down again

Restorations began around mid-morning UTC on August 5. Emails went out saying the blog had been reviewed and reinstated. Relief lasted, for many people, under an hour.

What follows is compiled from more than a dozen independent reports in the thread, and it forms a consistent pattern:

What the user did after restoration	Outcome
Edited the template HTML	Locked again
Uploaded/imported a theme to a new blog	New blog locked within minutes
Applied a theme change to an unaffected blog	Locked ~10 minutes later
Removed image gadgets from layout	Locked again
Inserted ad code into the theme	Locked again ~90 minutes later
Removed ad-network scripts from theme HTML	Locked again
Checked Mediavine settings	Locked ~5 minutes later
Clicked `Stats` in the dashboard	Locked immediately
Published a new post only	Mostly stayed up
Edited and republished existing posts/pages	Stayed up

One blogger stated the distinction outright after testing across several of their own blogs: removal fires after updating the homepage or making template changes, while editing and republishing posts or static pages leaves the blog alone.

Two independent users confirmed the sharpest version of this. Each created a brand-new blog and imported their content successfully — then applied their theme, and the fresh blog was disabled within minutes. One noted the new blog was fine right up until the theme upload.

The practical implication at the time: whatever misfired on August 4 appeared to re-evaluate a blog whenever the template or layout was written to. That held until Google shipped a fix.

What this meant then — and what applies now

During the incident, the guidance was to freeze the template completely: no theme edits, no gadget changes, no layout rearranging, no inserting or removing ad code. Reverting a change was itself a template write, and at least one publisher was re-locked doing exactly that.

That guidance is no longer in force. Blogger Product Experts have confirmed normal editing is safe again. The lasting takeaway is narrower but more useful: during any platform-wide enforcement event, stop writing to anything you don't have to write to. Publish nothing, change nothing, export everything. The blast radius of an automated classifier is widest at exactly the moment you are most tempted to fix things yourself.

One piece of housekeeping the Product Experts did recommend once things settled: clear out broken external links, since a link that now resolves to something unsafe is a genuine signal, and delete third-party scripts and gadgets you no longer use. Stale embedded code is both a performance drag and a real risk if the domain it loads from changes hands.

What is not causing this

Several theories circulating in Facebook groups and YouTube videos are contradicted by the thread itself:

"It's only custom/third-party themes." Popular among affected users, and templates from Templateify and other paid vendors do appear frequently. But a Brazilian blogger using a stock Blogger theme with only CSS tweaks for dark mode and rounded image corners was locked too. Custom themes may raise your odds; they are not a requirement.
"It's AdSense or ad networks." Blogs with no ads at all were hit, including a .blogspot.com subdomain with zero monetisation in the three-account test above.
"You must have added something." Blogs with no changes for months were locked. One had not been touched in over a year.
"It's a real malware infection." Search Console reports "No issues detected" for essentially every affected user who checked. Google Safe Browsing Transparency Report shows clean. VirusTotal shows clean. When Google's own security tooling disagrees with Google's enforcement system, the enforcement system is the outlier.

The pre-lock signals worth knowing about

Several users found anomalies in the hours immediately before their lock. These are individual reports rather than confirmed causes, but the cluster is interesting enough to document:

Bot floods. The perfume archive owner found roughly 400 bad bots hitting simultaneously in the minutes before removal, per StatCounter.
Suspicious traffic spikes. The Lombardy events blog saw traffic jump from a few hundred daily users to nearly 4,000, heavily from Singapore, Hong Kong and Tokyo, with about five seconds average engagement and an 86.9% homepage bounce rate — textbook automated traffic against a site whose audience is almost entirely Italian.
Crawler 429s. At least two users found Meta's Sharing Debugger receiving HTTP 429 (too many requests) from Google and being redirected to Google's /sorry/index anti-abuse page when trying to scrape their Blogger posts. Both say this began days before the lockdown.
Cloudflare blocking Googlebot. One owner discovered Cloudflare's Bot Fight Mode and Block AI Bots were returning 403 challenges to Google crawling IPs, and disabled them as a precaution.
Blogger API access. Two users had recently created Blogger API credentials for personal scripts. One deleted the credentials as a precaution.

If you run Cloudflare in front of a custom-domain Blogger blog, checking that Googlebot is not being challenged costs nothing and rules out one variable.

The 89-day clock

Here is the detail that should set your priorities, and it is printed on the lock screen itself rather than in the email: a removed blog is permanently deleted within 89 days.

That is your real deadline. Not the appeal, not the review — the point at which the content stops existing. Google's own Content Policy states that appeals are typically decided within 10 business days and that, unless noted otherwise, restrictive actions are global and permanent.

Eighty-nine days sounds generous. It is not, if your appeal sits unanswered for six weeks and you have not exported anything.

Back up first. Appeal second. If you only do one thing today, take the Takeout export.

Step 1: Request a review (the appeal)

There is no separate public appeal form. The appeal lives inside your dashboard.

Sign in at blogger.com.
If you have multiple blogs, click the blog name in the left sidebar to open the selector, and pick the one with a red exclamation mark next to its title.
Open the Info tab. Under "Note: this blog has been locked," click REQUEST REVIEW.
Some users also receive an appeal link directly in the removal email. Either route feeds the same queue.

Official policy: appeals are typically decided within 10 business days, though complex cases take longer. See Google's blogger policy.

If the Request Review button is missing or the form won't open

Multiple users hit this. Working around it:

Form redirects to your blog instead of opening. Sign out of all Google accounts, then sign back into only the account that owns the blog. Multi-account sessions are the usual cause. An incognito window works too.
No Request Review button under Info. Confirm you're on the right blog in the selector, and that you are the blog's Administrator rather than an Author. Authors do not see enforcement controls.
Email says "deleted" rather than "locked." These are different enforcement states. Several users with "deleted" emails still had the blog visible in the dashboard and could submit a review — check the dashboard regardless of what the email says.
The appeal dead-end. This one has no clean fix yet. Several users were reinstated, re-locked, and then found the appeal page told them their original appeal was already received and still under review, with no option to file a second one. If you are stuck here, post your case in the Blogger Help Community with your Blog ID so Product Experts can batch-escalate it. It is not satisfying, but it is currently the only channel.

What to include when you post to the community

Product Experts are volunteers, not Google staff, but they can escalate patterns. Give them something they can forward:

Blog URL and Blog ID (from the dashboard URL after blogId=)
Date and time of the lock, with timezone
The exact policy quoted in your email
Screenshot of Search Console showing Security Issues: No issues detected
Whether you were reinstated and then re-locked, and what you did in between

That last line is the most useful data point you can contribute right now.

Step 2: Back up with Google Takeout

Blogger's old one-click XML export in Settings is gone. Since July 1, 2025, Takeout is the only way to export posts, pages and comments.

Go to takeout.google.com
Click Deselect all
Scroll to Blogger and tick it
Choose Export once, or schedule exports every two months for a year
Pick .zip and a maximum file size. 2GB is fine for most blogs — if your archive is larger, Google splits it across multiple files automatically, so there is no wrong answer here
Choose a destination. Do not use Google Drive as your only copy — if your Google account is ever locked, your backup locks with it
Wait for the email with the download link. Minutes for small blogs, hours or days for large accounts
Download within one week. Google expires the archive after that

Does Takeout work while your blog is locked?

Yes. The Blogger Product Expert running the incident thread confirmed that anyone wanting to back up their blog should be able to do so even while it is locked, and linked users straight to the Blogger section of Takeout: takeout.google.com/settings/takeout/custom/blogger

A handful of users during the incident reported that exports were missing their posts, or that their blog was entirely absent from the archive. Given the confirmed guidance, the likely explanation is timing and queue delay rather than the lock state itself. Takeout snapshots on request; large accounts can take hours or days. If your first export looks wrong, request it again rather than concluding your content is gone.

One practical note from the same guidance: if you run many blogs, or one very old and large one, expect to download a substantial number of archive files.

Step 3: Understanding `feed.atom`

Unzip the Takeout archive and open the Blogs folder. Inside each blog's folder, two files matter:

File	Contains
`feed.atom`	Every post, page and comment, including drafts. The direct replacement for the old Settings XML export.
`theme-layouts.xml`	Your theme and most widgets.

Everything else can be deleted.

What you need to understand about feed.atom:

It is Atom XML, not Blogger's old export XML. Same information, different structure. Since June 2025, Blogger's Settings → Import content can read it — fixing a long-standing bug where restores silently drop posts and comments.
It includes draft posts. Genuinely useful if you lost drafts, and worth knowing for anyone whose unpublished work is now behind a padlock.
It contains no images. This is the one that catches people. feed.atom stores the HTML that renders your images from Google's servers under blogger.googleusercontent.com. The pictures themselves are not in the file. Takeout does export your image files separately — but only the ones uploaded by the account making the request. On a multi-author blog, your co-authors' images are only in their Takeout archive.
It preserves inline formatting only, not styling defined by your theme.
You can read it without Blogger. Open it in any text editor. It is dense XML and unpleasant to read, but your writing is in there. Several users pasted theirs into an AI tool to extract clean plain text — a reasonable move if you want a human-readable archive today rather than a restorable one.

That third point is the whole argument for treating feed.atom as a migration file rather than a backup. A backup whose images live on servers controlled by the company that just locked you out is not a backup in any meaningful sense.

Step 4: If you want to rebuild on Blogger

You can import feed.atom into a fresh blog via Settings → Import content. Two warnings, both from bloggers who tried it this week:

Do not import your theme. As documented above, this is what re-triggers the lock. Import content, use a stock Blogger theme, and wait.

Test on a dummy blog first. One reader found the safest route was to create a throwaway Blogger site, apply the theme there, and confirm it survived before touching the live blog. It would have cost five minutes and would have saved several people in the support thread a second lockout. Credit to commenter Lem Revival for posting this while the incident was still live.

Two things that can turn a false positive into a real violation

Both come directly from the Blogger Product Experts, and neither appears in most coverage of the incident.

Do not create a new blog to repost the same content. Duplicating your archive onto a fresh blog while the original is under appeal can itself be treated as spam, which would convert a mistaken enforcement into a genuine one. If you are rebuilding, do it because you have given up on the appeal, not alongside it.

Do not remove Blogger from your Google account. Deleting the Blogger service or your Blogger profile deletes your blogs, and it cannot be undone. This is worth saying plainly because it is exactly the kind of thing a frustrated publisher does at hour eighteen of an outage while trying to "reset" something. There is no undo, no appeal, and no Takeout export after the fact.

Read Google's policy line first. Blogger's Content Policy explicitly states that if you have had a blog disabled, you should not create a replacement blog engaging in similar activity. In a genuine false positive, that guidance is arguably unfair — but it is the written policy, and rebuilding while an appeal is pending carries some risk. Weigh it.

The custom domain trap

If you run a custom domain, this section matters.

It can be reconnected. One user confirmed it works: Takeout export, create a new blog, point the same domain at it, and republish gradually. They were about 10 posts into 1,139 and reported it going smoothly, aside from a slider in their paid theme not loading.

But you pay for it. As another user pointed out, search engines treat the reconnected domain as a new site. Crawl history, visit metrics and accumulated authority reset. And cycling a domain between deleted and new Blogger blogs repeatedly risks getting the domain itself flagged.

So: reconnecting works once, at a real SEO cost. It is a rescue, not a strategy. If you are going to move your domain anyway, moving it somewhere that cannot lock you out is a better use of the same disruption.

Step 5: Moving to WordPress

Let me be straight about the argument rather than dressing it up.

Blogger is free, and it has genuinely helped a lot of people for a very long time. Several blogs in that thread have been running since 2007. Nobody should feel foolish for having built there.

But this week established something concrete: an automated classifier at Google can remove your blog with no warning, no explanation, no human review, a ten-business-day appeal window, and an 89-day deletion clock. When it misfired at scale, the public accounting amounted to three sentences given to a news outlet — no postmortem, no affected-site count, no explanation of the fault.

People in that thread describe livelihoods stalled, AdSense applications caught mid-review, and 18 years of work sitting behind a padlock they could not open. Several could not access their own dashboard to inspect what had supposedly triggered it.

That is the actual risk profile. It has nothing to do with whether WordPress is nicer to use.

Why now specifically

Blogger has received essentially no meaningful development in years, while Google retired the services around it — Album Archive, FeedBurner's core features, and the one-click backup. The direction is maintenance mode. Meanwhile, the practical gap has closed: WordPress 6.9+ on entry-level shared hosting is fast enough to pass Core Web Vitals without a developer, and as AI-driven search reshapes referral traffic, owning your own schema, internal linking, and email list matters more than it did two years ago.

If you are going to move, moving before your archive grows another two years is cheaper and less painful.

The migration path, honestly

WordPress's built-in Blogger Importer is broken against the new export format — it was written for the old XML, and Google changed the file. Two free plugins handle feed.atom directly:

BtW Importer — upload the .atom file, imports in batches, downloads embedded images into your WordPress media library, rewrites Blogger URLs to local ones, and sets featured images from the first image in each post. Reviewers report ~80 posts per run; click again to resume.
Feed Importer for Blogger — same core job, also pulls images off Google's servers and rehosts them locally.

That image rehosting step is the entire point. It is what finally cuts your archive loose from blogger.googleusercontent.com. Until you do it, every image on your site is a link to a server Google controls.

One practical note the BtW Importer developer flags: Nginx-based hosts run these imports noticeably slower than Apache or LiteSpeed. For a large Blogger archive, this is the difference between an afternoon and a weekend of timeouts.

Do not skip redirects. Set up 301 redirects from your old Blogger URLs to the new permalinks, or you will lose the rankings you spent years building. On a custom domain, this is straightforward. On .blogspot.com you will lose some link equity — plan for it.

Hosting

For a migrating Blogger site specifically, Hostinger is a sensible landing spot: it runs LiteSpeed, which is the practical difference between a Blogger import that finishes and one that times out halfway through 1,000 posts. You also get free SSL, a free domain on annual plans, one-click WordPress install, and automatic daily backups you actually control.

Use code freeup at checkout for an extra 20% off the current plan price.

The honest version: no host makes you immune to everything. WordPress has its own exposure — we covered a critical REST API RCE in July. The difference is that you can patch your own server; you cannot patch someone else's classifier. What changes is who holds the off switch. On Hostinger, your posts sit in a MySQL database you can export any time, your images sit in a folder you can download, and no classifier can revoke your login at 2 AM.

Disclosure: Cyber Kendra earns a commission on purchases made through this link, at no additional cost to you. We recommend Hostinger because we use it.

Current status

As of August 12, 2026:

Resolved. Blogger Product Experts confirmed the root cause was fixed, with confirmation from the team responsible and an official announcement posted in the Spanish-language Blogger community.
Most affected blogs were restored within 24 to 48 hours of the initial lockout.
Normal editing is safe again, including themes and layout code.
Blogs still locked remain under review. Volume is the bottleneck, and blogs that never submitted a review request may not be queued at all.
Not every locked blog was a false positive — each case is reviewed individually.
Google's only public comment remains its three-sentence statement of August 5. No postmortem, no affected-blog count, and no technical explanation of the fault has been published.
The incident thread is now soft-locked, with 531 users reporting the same problem.

If your blog is back: export it today, leave your template alone, and treat the restoration as provisional.

FAQ

Is it safe to edit my Blogger theme or template now?

Yes. Blogger Product Experts confirmed on August 9 that publishers whose blogs were reinstated or were never affected can resume normal activity, including publishing posts and editing themes. The advice to hold off applied only while the faulty classifier was live.

My blog is still locked. What should I do?

Check that you actually submitted a Request review from the Info tab of your dashboard. Guidance from the Product Experts suggests that only blogs that requested a review are being reviewed, so an unappealed blog may not be in the queue. If you have already appealed, wait — the backlog is large, and resubmitting resets your place in it.

Why has my blog not been restored when everyone else's has?

Two possibilities. Either your appeal is still in the backlog, or your blog was not part of the false positive. The Product Experts made it clear that not all reports were misclassifications and that each case is assessed individually. If your blog has broken external links, outdated third-party scripts, or gadgets loading from domains that have changed hands, those are worth auditing on their own merits.

Can I create a new blog and repost my content while I wait?

No, and this one carries real risk. Duplicating your content onto a new blog while the original is under appeal can be treated as spam, turning a mistaken enforcement into a genuine violation. Wait for the appeal to conclude.

How long until my blog comes back?

No guarantee. Observed restorations ran roughly 6 to 20 hours from lock. Official policy allows up to 10 business days.

Will I lose my content?

Not if you act. Removed blogs are permanently deleted within 89 days. Export before then.

Can I check whether my blog really has malware?

Yes, and you should, so your appeal is honest. Check Search Console under Security Issues, the Google Safe Browsing Transparency Report, and run your domain through VirusTotal. Essentially, everyone who checked found all three clean.

My blog is locked, and I can't reach the dashboard. Can I still export?

Try Takeout — it works for some locked blogs and not others. Request it now, and again after restoration.

Should I delete my blog and start over?

No. Deleting forfeits your appeal and your 89 days.

Does this affect AdSense earnings?

While the blog is locked, it serves no ads and earns nothing. If you want to quantify what an outage like this costs, our AdSense earnings calculator will do the maths. Several users report pending AdSense applications caught mid-review.

Google never published a postmortem. If your blog is still locked, drop your Blog ID and appeal date in the comments — the pattern is still worth tracking.

What AI SOC tools are security teams deploying for Tier 1 work?

protalweb@gmail.com (Vivek Gurung) — Wed, 12 Aug 2026 21:59:46 +0530

On the 12th of August, 1914, barely a month into the First World War, the German 4th Cavalry Division, rattling their sabers and lances, charged directly into Belgian machine gun fire. It went about as well as you might expect. The new world triumphed over the old.

We’re currently seeing a similar situation playing out in contemporary SecOps.

Alert volume at AI-scale demands AI-enabled SOCs. Organizations that ignore that fact are already exposed. The organizations that have already recognized it are already reaping the benefits.

This article will explore how AI tools help SOCs keep pace with modern alert volumes by accelerating investigation, how to evaluate AI SOC platforms, and how to ensure AI doesn’t take too much control.

Why do you need an AI SOC Platform?

According to IBM's Cost of a Data Breach Report 2025, the global average cost of a breach dropped for the first time in five years, citing faster detection and containment through AI and automation as the reason. In fact, organizations using AI and automation extensively saved an average of $1.9 million per incident compared to those that didn't.

In 2026, however, the global average cost of a breach shot back up to a record $4.99 million. This increase was driven in no small part by a 56% increase in AI-generated attacks, and only 50% of organizations are deploying AI agents in their SOC.

These stats tell us that AI is the differentiator on both sides of the battle. In 2025, average costs fell as defender capabilities outpaced attackers’. By 2026, cybercriminals had turned the tables, using AI better and more widely than their victims.

If you want to stay safe in 2027, it’s clear that an AI SOC platform is the way to go.

What role can AI tools play in modern SOCs?

In a traditional SOC, analysts receiving an alert would have four tasks to complete. Those four tasks are where an analyst’s time goes, and they are why a queue of thousands of alerts cannot all receive a full review.

An AI SOC platform, however, can handle those tasks before a human sees them:

Matching indicators against threat intelligence: The AI automatically checks domains, hashes, and IPs against reputation feeds.
Pulling context from every telemetry source: Instead of an analyst switching between EDR, identity logs, cloud console, and network data, the AI assembles the relevant context into one view.
Correlating signals across systems: The system reads, for example, a login from a new location, a suspicious EDR event, and unusual cloud activity as a single picture rather than three separate alerts.
Producing a verdict with the reasoning attached: The output states what happened, why it matters, and what to do next. A human still makes the call, but the AI removes the legwork that once preceded it.

Those first two capabilities are all something a SOAR playbook can do with a fixed decision tree: if A, then B. The third bullet is something only an agentic AI SOC platform can do: leaving the scripted path when the evidence calls for it.

What is an AI SOC platform?

Chances are, the previous section piqued your interest. Automating investigation and making analysts’ lives easier is top of mind for most organizations.

But if you search for “AI SOC platform” online, the results can be confusing. That’s because “AI SOC platform” can mean several architecturally distinct things, and most vendor comparisons don't distinguish among them. So, here’s a quick explainer to help you make sense of it all.

AI-native investigation platform

In an AI-native investigation platform, AI runs the investigation end-to-end and returns a final verdict; a human then reviews the output. It’s the best solution for organizations looking to fully automate Tier 1 triage across the entire alert volume.

Vendors include:

Prophet Security
Dropzone AI
7ai

Prophet Security, one of the leading AI SOC platforms and a Rising in Cyber 2026 honoree voted on by more than 150 CISOs and security leaders, is a clear example of the category: an agentic AI SOC platform that investigates alerts like a senior analyst and returns a determination with the queries and evidence attached, running on the SIEM and EDR a team already owns.

Hyperautomation (SOAR + AI layer)

Hyperautomation just means that predefined playbook logic determines the path, and AI assists with scripted steps. It automates response workflows that are already mapped out.

Architecturally, hyperautomation is an AI layer over playbook logic, which means it inherits the engineering cost of that logic: the hours spent writing, testing, and maintaining the paths. That is a good fit for response workflows that an organization has already mapped, but a poor fit for problems whose paths are not known in advance.

Vendors include:

Torq
D3 Security

Copilot inside a SIEM or EDR

In this category, a human analyst decides, while AI suggests, summarizes, or takes bounded action inside that one product. It’s primarily used to assist an analyst already working in a parent vendor's console.

Vendors include:

CrowdStrike Charlotte AI
Microsoft Security Copilot

AI-Driven Managed Detection and Response

All the above categories assume that an organization already has an internal SOC team and is deciding what tool to give them. Managed detection and response tools, however, are for organizations that don’t have an internal team at all.

Confusion is particularly rife here because many managed providers market themselves with the same “AI-native” and “agentic” language as the tools above, even though they technically operate in a different category. One is a tool you operate, the other is a service that an external team operates for you.

How to evaluate an AI SOC platform?

You should now understand the differences between “AI SOC platforms.” You also (hopefully) know what type is the best fit for your organization. So, now you need to know how to distinguish between them at the evaluation stage.

A product demonstration alone isn’t going to tell you what you need to know. Asking whether the platform closes alerts on its own, or whether every action requires manual review, does. Asking that direction directly will expose more than a feature list will.

Similarly, Gartner's Hype Cycle for Security Operations, 2026 notes that much of what's sold as an "AI agent" - common on “AI SOC platform” homepages - is an AI assistant, which is limited in autonomy, and tied to one product.

If you’re truly looking for a product that can triage alerts on behalf of analysts, an AI assistant just isn’t going to cut it. Ask vendors whether their system takes the action itself, or whether a human still has to execute it. The former is an agent, the latter is an assistant.

The final thing worth checking before signing anything is whether the "autonomous triage" claim holds for your existing stack or only within the vendor's own SIEM and log pipeline. Some platforms genuinely run on top of what you already have. Others need you to migrate first, and that detail will usually only become apparent after a demo.

AI SOC platforms don’t replace human analysts - they just make their lives easier

One could be forgiven for assuming that AI is coming for analyst jobs. But that’s not the case.

Instead, the industry is moving toward a model where AI handles routine triage, and the analyst's job changes: less time spent working an alert queue, more time on edge cases, tuning detections, and hunting for what the system hasn't caught.

That's a harder (and much more rewarding) job than the one it replaces, not a smaller one. AI is essentially doing the grunt work that analysts would rather avoid.

For a closer look at what separates platforms built for that shift from those that only automate at their edges, GBHackers has put together a practical breakdown of the concrete capabilities to check when evaluating AI SOC platforms.

ShieldBreak PoC Bypasses Microsoft's RoguePlanet Defender Fix

protalweb@gmail.com (Vivek Gurung) — Wed, 12 Aug 2026 08:10:34 +0530

Security researcher Nightmare Eclipse has released ShieldBreak, a proof-of-concept exploit that defeats the patch Microsoft shipped five weeks ago for a Windows Defender privilege escalation flaw.

The researcher dropped the PoC code on GitHub and wrote that Microsoft has failed to properly patch the RoguePlanet vulnerability, CVE-2026-50656.

Two claims make ShieldBreak more dangerous than the exploit it replaces.

RoguePlanet was a race condition, and its reliability swung sharply from machine to machine. The researcher described it in June as hit or miss. ShieldBreak is listed with a 100 percent success rate.

The June exploit did not run on Windows Server, because standard users cannot mount ISO images there, though the researcher maintained server builds were vulnerable anyway. ShieldBreak is now listed as tested on Windows Server 2025, alongside Windows 11 25H2 and the Canary channel. Windows 10 stays vulnerable but unsupported by the current code. That pulls domain controllers and session hosts into scope for the first time.

The released code contains Warden.dll, a Report.wer Windows Error Reporting artifact, an eicar_com.zip antivirus test file, and supporting project files. The WER artifact is notable.

Analysts who dissected RoguePlanet in June described an attack chain built on NTFS junctions, opportunistic locks, and the Windows Error Reporting QueueReporting scheduled task, suggesting ShieldBreak reworks the same plumbing rather than opening a new front.

RoguePlanet surfaced on June 10 and targeted the Microsoft Malware Protection Engine, the scanner behind Defender, which runs as SYSTEM. It abused improper link resolution before file access to spawn a SYSTEM shell on fully updated machines. Microsoft rated it important at CVSS 7.8 and shipped engine build 1.1.26060.3008 on July 9. The Register reported that Redmond had closed every public zero-day the researcher disclosed.

It is the second fix in this class to fall. Microsoft hardened Defender's internal file-handling APIs in mid-May, and RoguePlanet was rewritten to defeat that. The release follows Microsoft's August Patch Tuesday, which fixed 421 CVEs on August 11. One of them touched Defender.

Nightmare Eclipse has published working exploits for unpatched Microsoft flaws since April, retaliation for what the researcher says was MSRC revoking their reporting access and refusing to pay bounties.

Previously disclosed flaws in the series include:

BlueHammer (CVE-2026-33825)
RedSun (CVE-2026-41091)
UnDefend (CVE-2026-45498)
YellowKey (CVE-2026-45585)
GreenPlasma (CVE-2026-45586)
MiniPlasma (CVE-2020-17103)
RoguePlanet (CVE-2026-50656)
GreatXML (CVE-2026-50661)

BlueHammer, RedSun, and UnDefend were exploited in real-world intrusions before fixes landed, and all three were added to CISA's Known Exploited Vulnerabilities catalog.

No patch exists for ShieldBreak, and no vendor has reproduced it publicly yet. ThreatLocker found that application allowlisting blocked RoguePlanet by default, the strongest control available for this bug class.

Microsoft had not commented on ShieldBreak at publication.

Anthropic to Watermark All Claude-Generated Text

protalweb@gmail.com (Vivek Gurung) — Tue, 11 Aug 2026 21:52:47 +0530

Anthropic has detailed plans to mark content generated by its Claude models, embedding invisible watermarks directly into generated text and attaching cryptographically signed provenance metadata to generated files.

The company set out the approach in a support document confirming it has signed the EU AI Act's Article 50(2) Code of Practice on Transparency of AI-Generated Content, as a provider of both generative AI models and generative AI systems.

The document is framed throughout as a description of how Anthropic is "planning to put those commitments into practice", and the company says it will publish more detailed technical guidance as it becomes available.

Claude models launched in the EU on or after 2 August 2026 will support machine-readable marking at launch, according to the company. Anthropic says it is also working to add marking support to models released before that date, which fall under a transition period allowed by the law.

Two marking mechanisms

Anthropic is deploying two techniques that address different failure modes.

The first is an embedded text watermark. According to the company, when a supported model generates text, it weaves an imperceptible mark into the text itself, without changing meaning, quality or readability. Because the mark is carried by the text rather than attached to it, Anthropic says it travels through copy-and-paste and may survive some editing.

The second is signed provenance metadata on generated files. For supported formats including SVG, PNG and JPEG, Claude attaches metadata conforming to the Coalition for Content Provenance and Authenticity (C2PA) open standard. Anthropic says a signed label indicates a file was processed by Claude and allows detection of subsequent tampering.

The distinction matters in practice. Metadata is information-rich but fragile — it does not survive screenshots, format conversion or most CDN image pipelines. Watermarks carry far less information but persist through transformations that destroy metadata. Deploying both is what makes the pair complementary rather than redundant: each covers the other's principal failure mode.

Applies worldwide, across every surface

Although the commitments originate in EU law, Anthropic states that marking will apply to output from supported models wherever Claude is offered, worldwide.

Coverage spans the Claude Platform API, the Claude consumer apps, Claude Code, Claude Cowork and Claude Tag. Embedded watermarks will also apply when supported models are accessed through AWS, Google Cloud and Microsoft Foundry, though Anthropic notes that signed provenance metadata may not be supported on every cloud platform, depending on the features each offers.

Anthropic says watermarking is applied at the model level, meaning it is present regardless of which product or surface the text comes from.

Detection remains unavailable

The company says it will support users and third parties in detecting Claude's marks, as the Code requires, with details to follow in forthcoming technical documentation.

Until those ships, the text watermark is unverifiable by anyone outside Anthropic. Keyed text watermarking schemes bias token selection during generation according to a secret; confirming the signal requires that secret. Google's SynthID text watermarking runs on Gemini output, but its detector remains restricted to Google and selected enterprise partners, and OpenAI has not deployed a detectable text watermark despite publishing research on the technique.

The practical consequence is a gap between marking and verification. Once marking is live, output will carry a signal that no publisher, platform or academic institution can currently read.

The C2PA file metadata is a different matter — it uses an open standard with public tooling, so anyone can verify it today using the C2PA verification tool, c2patool, or any C2PA-compatible reader.

Anthropic's own caveats

The support document is unusually direct about what marks do not establish.

A detected mark indicates content may have been processed by Claude, but it is not conclusive. Anthropic notes that people routinely use Claude to proofread, translate, summarise or convert files, so output can carry a mark even when the underlying ideas or text originated elsewhere. Marked content may also be edited, excerpted or combined with other material afterwards.

The reverse holds more strongly. Anthropic lists several conditions under which genuinely AI-generated content will carry no detectable mark: generation by a model predating marking support, heavy editing or paraphrasing, translation, passages too short to carry a reliable signal, metadata stripped through format conversion or re-saving, and platforms or file types where a marking type is not supported.

For anyone building detection into an editorial or compliance workflow, that asymmetry is the operative fact. A mark found is evidence. A mark absent is nothing at all.

What it means for publishers

Organisations deploying Claude in their own products carry independent obligations. Anthropic says those building with Claude should assess what Article 50 requires of their own products and services, and that it will publish technical guidance to support those obligations.

For publishers, the near-term implication is narrower than it first appears. Text watermarks cannot be checked by anyone yet. File credentials can be, and any newsroom accepting image submissions can start verifying them today — a valid credential identifies the signing tool, the certificate holder, and the exact time of signing, and proves whether the file has changed since.

YouTube Now Wants 8,000 Watch Hours for Monetisation

protalweb@gmail.com (Vivek Gurung) — Tue, 11 Aug 2026 00:40:01 +0530

Most of the attention on YouTube's August 10 announcement went to the double-entry bar for newcomers. The change with longer teeth applies to the three million creators already inside the YouTube Partner Program (YPP).

From February 1, 2027, a channel must hold 10 million qualified Shorts views across a rolling 90-day window to draw from the Shorts Creator Pool each month. Fall short, and Short's payouts pause. YouTube says such channels stay in the program and keep earning on long-form video, with Shorts revenue resuming automatically once views recover — missing the mark does not mean removal from YPP, and other earnings are unaffected.

That quietly converts monetization from a milestone you cross once into a test you re-sit every quarter. The shift matters in India, where creators lean on sheer volume because RPM (revenue per thousand views) sits well below Western rates.

New applicants face a steeper climb. They will need 1,000 subscribers plus either 8,000 qualified watch hours over 365 days or 20 million Shorts views in 90 days — double the current 4,000 hours and 10 million views. Fan funding, Shopping and Creator Partnerships stay open at 500 subscribers.

The money side moves too. Premium Lite expands to every country where Premium is sold. Subscription income is pooled — 60% of net revenue for Premium Lite, 30% for Premium — divided by member watch time, then shared 55% for long-form and 45% for Shorts. A separate 45% direct share applies when an advertiser targets five or fewer channels.

YouTube frames the package as "meaningfully rewarding active creators" and expects to pay out more in 2027 than in 2026. Set against the 200 billion Shorts views it serves daily, the subtext is arithmetic: the pool is not growing as fast as the number of hands reaching into it. Promised bonuses for Shopping, brand deals and trend-starting are meant to cover smaller channels, but specifics remain unpublished.

What creators should do now: review and accept the updated terms in YouTube Studio before January 31, 2027, to keep full monetisation. Channels hovering near the 10 million mark should watch the rolling 90-day count in Analytics rather than monthly totals, and treat long-form uploads as the steadier floor under their earnings.

Microsoft Leaves Windows Passkey Prompt Spoofing Unfixed

protalweb@gmail.com (Vivek Gurung) — Tue, 11 Aug 2026 00:09:06 +0530

Three weeks before Microsoft makes passkeys the default sign-in method for Entra ID, new research shows that the Windows dialog protecting them can be faked well enough to fool the people who build security products for a living — and that Microsoft has decided the underlying weakness isn't worth patching.

The finding comes from SpecterOps principal security researcher Michael Grafnetter, who presented Pass-the-Passkey Family of Attacks at Black Hat USA 2026 on August 5 and published a 72-page white paper alongside it.

The research documents three zero-days in Windows 11 and Microsoft Entra ID, more than 20 attack techniques, and a toolkit that SpecterOps has open-sourced so defenders and pentesters can reproduce the attacks.

Two of the three bugs have been fixed. The third has not, and it is arguably the one that matters most going forward.

The chain Microsoft closed

Grafnetter's team found that Windows 11 was writing complete WebAuthn assertions — the signed responses a passkey produces to prove who you are — into the Microsoft-Windows-WebAuthN/Operational event log in plaintext. Every field an attacker needs was there: challenge, authenticator data, signature, credential ID, and user handle.

Reading that log locally required nothing more than membership in the Users group. Remotely, membership in Event Log Readers, Remote Desktop Users, Remote Management Users, or Administrators was enough.

The logging applies to Windows Hello, YubiKeys, password-manager plugins, and phone-based hybrid flows alike. The only exceptions were private browsing sessions and password managers that autofill passkeys without touching the Windows API.

On its own, a leaked assertion is stale data. The second flaw made it live ammunition: Entra ID was not checking whether a challenge had already been used, was not binding challenges to a session, and was not tracking signature counters — three of the anti-replay checks the WebAuthn Level 3 specification assigns to the relying party. Entra ID's challenges are short-lived signed JWTs valid for five minutes, but the service accepted them for roughly ten.

Put together, a low-privileged user on a shared or managed machine could lift a Global Administrator's assertion out of the event log and replay it, satisfying the phishing-resistant MFA requirement in Conditional Access along the way. In testing against Microsoft 365 E5 tenants with Entra Identity Protection and Defender for Identity enabled, the researchers saw no alerts at all.

Microsoft patched the Windows side on July 14 as CVE-2026-34348, truncating the logged signature to six bytes so the events remain useful for debugging but useless for replay. It classified the issue as information disclosure at CVSS 6.5; SpecterOps had filed it as privilege escalation at 8.6.

The cloud fix arrived quietly in May — Grafnetter says he only noticed it while recording demos for the conference. Notably, that fix covers FIDO2 security keys, not Windows Hello on Entra-registered devices, which still reports a signature counter of zero.

The one that stayed open

The unpatched issue is smaller in scope and larger in practical consequence. The Win32 function WebAuthNAuthenticatorGetAssertion, documented in Microsoft's own header, takes a window handle (hWnd) that determines which application the credential dialog appears to belong to. Windows does not validate it. Malware can therefore render the "Sign in with a passkey" prompt as a modal child window of Microsoft Edge or Outlook — even when those apps are running under a different user account.

Pair that with a second trick from the paper: the publisher name shown in the prompt comes from the executable's version resource, which the attacker controls. Setting an assembly title of "Microsoft Edge" and an author of "Microsoft Corporation" produces a dialog that reads Requested by Microsoft Edge (Microsoft Corporation) — the exact string a cautious user would look for.

Because malware calling the API directly supplies its own origin, rather than having the browser fill it in from the page, it can request an assertion for any site it likes. Windows blocks two ceremonies at once, so overlaying a rogue prompt on a real one fails — but simply waiting for the legitimate login to finish and then prompting works fine, and a flooding mode re-prompts every couple of seconds until the challenge expires.

The paper is blunt about how effective this is, noting that colleagues admitted to confirming such prompts "reflexively," without checking what they were approving.

Microsoft's Security Response Center reviewed a proof of concept and closed the case on June 4 as low-severity "Defense in Depth." SpecterOps scored it 8.0 High.

Wider exposure

The white paper covers a lot more ground than the three CVE-class issues. Windows relays passkey prompts over RDP and Hyper-V enhanced sessions by default via MS-RDPEWA, so malware on a compromised jump host can raise a prompt on the administrator's own desktop.

Administrative passkey registration APIs in Microsoft Graph and Okta can be abused to plant a "shadow passkey" that survives a password reset. And synced passkeys are exportable in cleartext by design: KeePassXC writes .passkey files in the clear, Bitwarden's default JSON export is unencrypted, and the FIDO Alliance's Credential Exchange Format leaves transport protection to the provider. Any of those files is a working credential to anyone who finds it.

What to do now

Grafnetter is not telling anyone to abandon passkeys. "Passkeys are still a major improvement over passwords, but they are not magic," he told Dark Reading.

For IT administrators, the practical steps are: apply the July 2026 Windows updates; stop treating phishing-resistant MFA in Conditional Access as a sufficient control on its own; issue device-bound passkeys and enforce attestation for privileged accounts instead of synced ones; restrict remote event log access and use privileged access workstations for admin work; and audit passkey registrations through Graph and Okta APIs.

On the detection side, SpecterOps flags several signals worth hunting for: WebAuthn API calls from non-browser processes, unexpected reads of the WebAuthN operational log, enumeration of top-level window handles, and DLL injection into browsers. Any one of them is noisy on its own; correlated, they're a strong indicator.

For developers, the advice is simpler — bind challenges to sessions the way GitHub already does, enforce single-use challenges and signature counters, use a maintained WebAuthn SDK rather than rolling your own, and keep assertions out of your logs.

And for everyone else: if a passkey prompt appears when you weren't signing in to anything, cancel it. Twice, if you have to.

Windows 11 Kernel 0day PoC Drops Before Patch Tuesday

protalweb@gmail.com (Vivek Gurung) — Mon, 10 Aug 2026 23:31:09 +0530

An anonymous researcher has published proof-of-concept (PoC) code for what they describe as an unpatched local privilege-escalation flaw in Windows 11, posting the writeup online just a day before Microsoft's August Patch Tuesday. If the claims hold, a standard user on a fully updated Windows 11 25H2 machine could use the bug to push code toward SYSTEM-level control — the highest privilege on the box.

The vulnerability, tagged CVE-2026-62737 by its finder, does not yet appear in Microsoft's advisory database or the National Vulnerability Database, and Microsoft has not confirmed it. The researcher says the PoC still fires on the latest Windows build and released a crash dump as evidence, while deliberately withholding the full exploit.

The flaw sits in ExecutionContext.sys, a genuine Microsoft-signed kernel driver that has shipped with Windows since at least 2021 and is documented as the "CPU Scheduler for High Performance I/O." It is a demand-start component that does not run by default.

According to the writeup, a loader/proxy path inside Windows' NDIS networking stack re-exposes this access-controlled device to low-privilege users, sidestepping the permissions (ACL) meant to keep them out. From there, the driver accepts a user-supplied function pointer and passes it to a kernel worker thread, which runs it after only checking that the address falls inside kernel memory.

It never verifies who supplied the pointer or whether it is legitimate enough, the researcher argues, to redirect kernel execution.

The disclosure fits a pattern that has defined 2026: researchers racing to drop kernel PoCs around each Patch Tuesday, which have swelled to record sizes, with Microsoft fixing more than 600 flaws in a single recent month.

This author frames the bug as an AI-assisted find, claiming large language models handled the tedious code-audit work that once took weeks. "After years of relative stability, the Patch Tuesday process has experienced significant turbulence," Rapid7's Adam Barnett said of the 2026 cadence.

On its own, the PoC only forces a blue-screen crash, not a working SYSTEM shell; a full exploit needs a separate kernel-address (KASLR) leak to line up. And while the targeted driver is genuine, the vulnerability itself is not yet confirmed — Microsoft has not acknowledged it, and no other researcher has reproduced the finding.

Defenders should watch tomorrow's Patch Tuesday release for a matching fix and deploy it fast, since privilege-escalation bugs are usually the second stage of a breach rather than the way in. Until Microsoft weighs in, limiting who can run untrusted code on shared and multi-user systems — and watching for unexplained crashes in the affected driver — remains the practical hedge.

DeadLock Ransomware Puts Its Negotiation Portal On-Chain

protalweb@gmail.com (Vivek Gurung) — Mon, 10 Aug 2026 22:54:08 +0530

Every ransomware crew eventually loses its website. DeadLock's operators appear to have decided not to have one.

Microsoft Threat Intelligence has published a technical breakdown of the Rust-based DeadLock encryptor, and the most consequential finding isn't in the crypto — it's in the ransom note. The file DeadLock drops on desktops and drives roots, RECOVERY_CHAT.<UID>.html, is a complete single-page web application: encrypted chat, a paginated leak blog, and an S3 file browser, all running in the victim's browser with no conventional backend behind it.

Instead of a hardcoded onion address, the page fires read-only eth_call requests at six public Polygon RPC endpoints to reach two smart contracts. One stores the URL of the operators' chat proxy; the other holds the leak blog posts.

Knock the proxy offline, and the crew simply updates the on-chain value — every note already sitting on victim machines starts pointing at the replacement. Stolen files are parked in Wasabi buckets, browsable through pre-signed URLs that the note generates on the fly. Microsoft calls the setup "a notable evolution in ransomware infrastructure design."

Victim-operator chat rides the Session network, an onion-routed messenger with no central server. The victim's Session identity is derived by hashing their chosen login and password with SHA-512 — no registration, and no recovery if they forget the combination.

DeadLock surfaced in July 2025 and had listed more than 80 organizations on its leak site by July 2026, over half of them European. Microsoft has watched multiple crews deploy it, including an affiliate of the Lynx and INC operations, against IT, mining, logistics, manufacturing, and hospitality targets across five continents.

A dispatch thread checks system load before releasing each file to a worker and stalls whenever memory use tops 29%, or CPU idle falls below 30%, keeping infected machines responsive and resource graphs unremarkable.

Large files get intermittent 512-byte-block encryption instead of a full pass. Before any of that, it disables Defender, VSS, and backup services, empties the recycle bin across all drives, and clears event logs three different ways — including flipping Enabled to 0 on every WINEVT channel. Machines set to Russian, Persian, Arabic (Oman or Yemen), or a dozen other CIS-region locales are skipped, and the binary self-deletes.

File encryption pairs Curve25519 with XChaCha20 using per-file ephemeral keys. Microsoft found no practical path to decryption without the operators' private key, so recovery comes down to backups.

Defender flags samples as Ransom:Win32/Deadlock.*. Microsoft's guidance: enable tamper protection, run EDR in block mode, tighten Controlled Folder Access, and switch on the ASR rules blocking PsExec/WMI process creation and low-prevalence executables. The encryptor's SHA-256 is a1fdf65020ce4a0f0940c793c6425baf8a0b994ec48b9baaf72788661a9d29f4.

Researchers Buy 'No Reply' Domains and Get Company Data

protalweb@gmail.com (Vivek Gurung) — Sat, 8 Aug 2026 23:07:46 +0530

Fifteen dollars is roughly what it costs to start reading email your company thinks nobody receives. Two security researchers who quietly bought placeholder domains — the ones enterprise systems fall back on when an address is retired or an alert needs a fake sender — have collected hundreds of thousands of misdirected corporate messages, and their own scanning suggests hundreds of similar domains are already sitting on live inboxes.

Cory Solovewicz, a security researcher and consultant, laid out the problem at the Defcon security conference this week. He registered noreply.us in 2020, intending to use it as a personal catch-all (an inbox that accepts mail sent to any address on a domain), then noticed that unrelated corporate systems were already mailing it. "I created an accidental honeypot," he told WIRED.

The volume since has been extraordinary. His noreply.net domain, bought in 2024, has taken close to 400,000 messages in about 18 months, 28,365 of them carrying attachments.

The mail arrives from more than 14,000 sending addresses across 6,200 root domains, all of it machine-generated: injury reports from a city government, service tickets, school platform signups, and, repeatedly, credentials for test environments.

Mike Sheward, head of security at EV charging company Xeal, ran the same experiment with deleteduser.com. Three organisations emailed it within the first hour. Since then, he has received leave-approval requests, hotel bookings with full guest names, Zoom invites from a UK government agency, and thousands of CCTV stills from an AI vendor monitoring worker safety at Middle East industrial sites — traffic from at least 100 organisations, several of them security vendors themselves.

Rather than deprovisioning an account, many systems simply rewrite the user's address to a placeholder domain the company does not own. Brian Krebs documented the same failure with donotreply.com nearly two decades ago.

The exposure is wider than two inboxes. Solovewicz probed 7,136 candidate placeholder domains and found 328 with catch-all inboxes already configured.

Fixing it is cheap: audit outbound mail for external placeholder domains, switch no-reply senders to a subdomain you control or to .invalid (reserved by RFC 2606 and guaranteed never to resolve), and make account deletion actually delete rather than rename.