Your once excellent hosting company has gone all-in on AI and you can't reach a person?

I’ve been in the web hosting business for a long time, and I remember when getting help from your hosting company was pretty simple.

You sent an email. A real person answered.

Better yet, after a while they might actually recognize your name, know something about your website, and understand what you were talking about without making you explain everything from scratch.

Somewhere along the way, a lot of hosting companies decided that was too expensive.

Now we’re hearing the same story over and over from website owners.

A host they once loved gets bought, grows rapidly, or simply decides to “modernize” its support. You're favorite tech support guy Bob gets "promoted" and no longer available to help. Staff gets reduced apparently there's no one answers their phone anymore. And AI chatbots have since become the front door.

That may work fine when the question is, “How do I change my password?”

It’s a little different when your website suddenly disappears.

Or your email stops working.

Or a WordPress update breaks something.

Or you wake up to discover your website has been hacked.

That’s when you find yourself explaining the same problem to a chatbot for the third time while wondering whether there is still an actual human being somewhere in the building.

---

But I don’t believe the purpose of AI should be to keep customers away from the people who can actually help them.

AI should make a good technician better. It shouldn’t replace the technician.

When you email TVCNet, a real person answers. And not someone working from a script. You’re talking with people who actually work with cPanel, WordPress, DNS, email, migrations, malware and hacked websites every day.

Want to talk to somebody? Call.

Website hacked? TVCNet can clean it up.

Thinking about moving? A person at TVCNet will migrate your websites for free.

It’s an old-fashioned approach to customer service that the people at TVCNet enjoy.

Funny thing is, with the direction much of the hosting industry is heading, old-fashioned is starting to feel pretty darn good again.

If your current hosting company seems more interested in keeping you talking to its AI than talking to you itself, maybe it’s time to see what the other side looks like.

Call anytime.

⚠️ WordPress 7.1.3 is now available and fixes 7 security vulnerabilities in WordPress Core, along with 4 additional bugs.

The most important fixes include:

🔹 Stored XSS through pending comments
Malicious code could potentially run when an administrator opens the Comments moderation screen.

🔹 SQL injection in the WordPress export system
Malicious input could remain hidden until someone runs a WordPress export.

🔹 Private comments exposed
Comments on private or unpublished posts could potentially be viewed by visitors who were not logged in.

🔹 Additional fixes
WordPress also patched an Imgur embed XSS issue, a denial-of-service bug, and several permissions-related vulnerabilities.

Interestingly, Anthropic reported 3 of the 7 vulnerabilities, with others reported by Trail of Bits, Patchstack, independent researchers, and the WordPress security team.

There are currently no known reports of these 7.1.3 vulnerabilities being actively exploited.

Still, I recommend updating sooner rather than later.

✅ Update WordPress Core to 7.1.3
✅ Confirm your backups are current
✅ Check older WordPress installations carefully, since some security fixes are still being backported

If automatic Core updates are enabled, your site may already be updated. See:
Dashboard → Updates

Stay patched!

Every so often WordPress pushes a security release that's more than routine, and this is one of those weeks.

WordPress 7.1.2 came out on September 22 to fix a critical bug that can lead to remote code execution. It affects every version all the way back to 4.7, and in some instances an attacker doesn't need to log in to try it.

If you're thinking "didn't we just update for 7.1.1 last week?" you're not imagining it.

That was only five days earlier. The Core team is moving fast right now, and that alone tells us something [hint].

For TVCNet and HackGuard customers, the priority is simple: confirm you're actually on 7.1.2 or the matching backport. Don't assume auto-updates just quietly happened in the background. It very likely hasn't...

If a site does get compromised through a bug like this, cleanup isn't just replacing infected files. It's a credential incident too.

Passwords, wp-config, admin accounts and hosting panel logins all get treated as potentially exposed.

One more thing this week, and this one is the bigger picture:

- Security researchers just documented a malware family that hides inside Must-Use plugins, so it never shows up on your normal Plugins screen.

- It uses the Ethereum blockchain to find its command servers, which makes it hard to shut down.

- It can quietly steal admin details, payment settings and customer order data, it's designed to rebuild itself after removal, and it may try to spread to other sites under the same account.

That kind of persistence is exactly why, if your site is hacked, we look beyond the dashboard, and why one compromised site sometimes means the whole account needs a closer look as well.

In short: patch fast, verify, and if something looks off, ask. We are here to help.

If you're on HackGuard, we're watching and we'll reach out if action is needed. If you're not, and this lands a little too close to home, that's what we're here for.

Are you tired of your hosting company's outages, or poor customer service, and looking for a new home for your website?

TVCNet makes it easy. With our free migration and help in migrating and updating your DNS to our servers we can have you moved over in a day.

Just give us a call and we'll make it happen today!

https://preview.redd.it/o9oh6r0r90jh1.png?width=1076&format=png&auto=webp&s=19acbc4e58d706c0137200f69538d433386fa4ec

If you are wondering why your clients are seeing their bandwidth or website load times spike over the past couple of months, well, here you go- blame it on AI...

Spoofing & Security. See which agents are most frequently impersonated and how spoofing activity changes over time. A visit is considered spoofed when it claims a recognized agent identity but fails that agent's supported authentication method:

A supply chain hit has just taken down the BdThemes lineup, disabling popular plugins like Element Pack and Prime Slider on the official WordPress directory. This is not your typical code hack. They did not touch any files on the WordPress servers. Instead, they went upstream and poisoned the remote static JSON feed that pushes promotional banners into the admin dashboard.
___
Element Pack Addons for Elementor, Prime Slider Addons for Elementor, Pixel Gallery Addons for Elementor, Ultimate Post Kit Addons for Elementor, Ultimate Store Kit, Live Copy Paste for Elementor, Smart Admin Assistant.
----

In short, an escaping flaw allowed malicious data from that feed to execute JavaScript whenever an administrator loaded a WordPress admin page. The injected JavaScript could silently create rogue administrators, install a web shell, and establish persistent backdoors. Yeah, that's not good.

Why is this important?
The plugin files themselves did not need to be altered.
Let's let that sink in for a moment...

https://preview.redd.it/wa22w0vsneih1.png?width=791&format=png&auto=webp&s=9cc4ad1c533796ddc8394ebba6bf7070c7a3126d

WordPress took a beating this past month. The newest AI models are finding and writing code to exploit vulnerabilities that sat hidden for years.

Nobody caught them until these latest model releases. So now we are dealing with the fallout...

WordPress 7.0.3 officially dropped today, August 6, as a new security release.

The recent security reality.
The WordPress.org core team forced a background auto-update for 7.0.2 in July to handle active exploits.

What was patched in July?
- Patched one critical-severity flaw.
- Patched one high-severity flaw.

Version 7.0.3 follows right on its heels. Given the current wave of AI-driven attacks, you want to apply this patch immediately.

Those 7.0 branch fixes?
The 7.0 branch was a significant upgrade, to say the least. It dropped native AI engine frameworks and fixed server-side memory leaks that previously choked websites.

And version 7.0.1 knocked out 31 bugs in the block editor, fixed media library folder-view errors, and cleaned up display issues in the new admin dashboard.

I think, all told, the core team resolved over 700 bugs across core and Gutenberg. So for those folks who say the WordPress dev team has fallen asleep on the job, well, I'd say more like three Red Bulls a day...

Do not wait on this. Log into your dashboard, run a backup, and apply the 7.0.3 update.

https://preview.redd.it/y3wg4dslfthh1.png?width=575&format=png&auto=webp&s=b11a3495980f61d30753e969ebc9efed0c79f406

Question:
What's a little-known secret about TVCNet?

Answer:
If you pay for hosting annually instead of monthly, you get free space.

So if you are looking for a nice discount and your site uses more than a couple of gigabytes of space, just let TVCNet double your allowance for free by upgrading from monthly to yearly.

2027 will be an exponentially challenging year for WordPress.

For most of WordPress’s history, building and maintaining the PHP code that powers plugins, themes, and WordPress itself required a real skill set. It required experience, patience, and a special kind of concentration.

That has changed.

In 2026, WordPress entered what I would call its unveiling year.

By unveiling, I mean that the barrier to both creating WordPress code and finding weaknesses in WordPress code has collapsed. Pretty much anyone with a basic education, a few dollars, and access to modern AI tools can now generate plugins, build themes, review PHP, test code paths, and discover vulnerabilities that previously required years of specialized experience.

That shift is not coming someday. It is already here.

This past week made that painfully clear. WordPress Core received an emergency security release after serious vulnerabilities were discovered and patched. Reporting around the issue indicated that AI tooling was involved in developing or validating the exploit chain. Whether one prompt or many, whether cheap or expensive, the larger point remains the same:

The old assumptions no longer hold. The ability to find exploitable PHP vulnerabilities is now available to everyone.

For years, WordPress security has depended on a mix of responsible disclosure, plugin developer responsiveness, managed hosting protections, security plugins, vulnerability databases, and the quiet assumption that finding exploitable bugs still required enough expertise to slow attackers down. That assumption is disappearing.

The Avalanche Problem

The greatest threat to WordPress is not only the next vulnerability in Core. It is the vast installed base of old plugins and themes.

WordPress has succeeded because it made publishing easy and extensibility nearly unlimited. That same success has created a security problem of historic scale.

There are millions of WordPress sites running plugins and themes written years ago, often by developers who have moved on, businesses that no longer exist, or maintainers who never expected their code to be reviewed by AI powered vulnerability testing tools.

Many of these plugins work fine. Many of them are useful. Many of them also contain insecure patterns that were common, unnoticed, or simply not understood at the time they were written.

In the past, those weaknesses were discovered slowly. A researcher found one. A botnet found another. A security company published a notice. A plugin developer released a patch, or did not. That pace is about to change.

As AI assisted code review and exploit generation become built into everyday tools, WordPress will face an avalanche of vulnerability reports, emergency patches, abandoned plugins, active exploitation campaigns, and confused site owners who have no idea which warnings matter and which actions are safe.

This is not a future where security remains a side concern. This is a future where security becomes the main feature WordPress must deliver.

WordPress Needs Security as a Native Product Feature

WordPress cannot depend forever on every site owner installing the right security plugin, choosing the right host, subscribing to the right vulnerability feed, understanding CVEs, reading patch notes, and manually deciding what to do when a plugin becomes dangerous. That model does not scale.

WordPress needs a native security layer that treats plugin and theme risk as a first class part of the platform.

In plain terms, WordPress Core should know when installed code is vulnerable, understand the likely severity, communicate clearly to the site owner, and take safe protective action when possible.

This does not mean WordPress needs to replace Patchstack, WPScan, Wordfence, hosts, researchers, or the existing security ecosystem.

It means WordPress needs to learn from them and bring the most essential protections into the platform itself.

What WordPress Core Should Build

1. A Native Vulnerability Intelligence Feed

WordPress should maintain or integrate a signed, trusted vulnerability feed for plugins, themes, and Core.

Every WordPress site should be able to answer basic questions without requiring a third party plugin:

• Is this installed plugin known to be vulnerable?
• Is the vulnerable version currently installed?
• Is there a safe update available?
• Is the plugin abandoned?
• Is exploitation active in the wild?
• Is this vulnerability remotely exploitable?
• Does it require authentication?
• Is there a temporary mitigation?

This information should appear directly in the WordPress admin, in Site Health, in Updates, and in a dedicated Security screen.

Site owners should not have to understand the difference between a theoretical vulnerability, a patched vulnerability, and an actively exploited vulnerability by reading scattered blog posts. WordPress should tell them plainly.

2. Vulnerability Aware Automatic Updates

WordPress already supports automatic updates, but security updates need a more intelligent model.

When a plugin or theme has a serious known vulnerability, WordPress should be able to prioritize that update differently from a routine feature release.

A modern security update system should include:

• automatic backup before high risk security updates
• compatibility checks where possible
• staged update attempts
• automatic rollback if the update breaks the site
• clear owner notification
• emergency update escalation for critical vulnerabilities
• host level coordination where available

If a vulnerability is being actively exploited, WordPress should not treat the update as just another available plugin update. It should treat it as a site safety event.

3. Temporary Virtual Patching

WordPress should explore a native virtual patching layer for known plugin and theme vulnerabilities. This is one of the most important ideas we should consider.

When a vulnerable plugin cannot be updated immediately, WordPress should be able to apply narrow, temporary protections that block known exploit patterns until the real patch is installed.

That could include protections around:

• dangerous request parameters
• unauthenticated AJAX actions
• vulnerable REST routes
• unsafe file upload paths
• known option changes
• privilege escalation patterns
• SQL injection signatures
• cross site scripting payloads

This does not need to become a full web application firewall inside Core.

But WordPress should be able to receive signed mitigation rules for known vulnerabilities and apply limited, targeted protection.

Patchstack has already shown that vulnerability intelligence and virtual patching can be productized. I'm not saying that WordPress should not copy a commercial service wholesale, but it should recognize the model as essential infrastructure.

4. A Plugin Permission Model

One of WordPress’s deepest security problems is that plugins generally receive enormous trust.

A simple plugin can often touch the database, create users, handle uploads, register REST routes, add AJAX actions, modify options, and execute powerful code.

WordPress needs a permission model that makes plugin capabilities visible and, over time, controllable. Site owners should be able to see what a plugin is allowed to do.

For example:

• Can this plugin create administrator users?
• Can it write files?
• Can it process uploads?
• Can it expose public REST API endpoints?
• Can it modify site options?
• Can it send email?
• Can it execute scheduled tasks?
• Can it access customer or user data?

This would be a major architectural challenge, but WordPress needs to start moving in this direction.

The plugin ecosystem was built for trust. The AI exploitation era requires boundaries.

5. Plugin Isolation and Restricted Execution

WordPress should begin developing ways to isolate risky plugin behavior. Not every plugin needs full access to everything.

Over time, WordPress could introduce restricted plugin modes, stronger sandboxing patterns, safer APIs, and warnings when plugins use dangerous functions or outdated practices. Even partial isolation would help.

A contact form plugin should not casually have the same practical power as a backup plugin, a membership plugin, or an ecommerce plugin. The current all or nothing model is too dangerous for the next phase of the web.

6. Continuous AI Assisted Directory Scanning

If AI tools can be used to find vulnerabilities by attackers, they should also be used continuously by WordPress.org. At a minimum:

• Every plugin and theme in the official directories should be scanned regularly using static analysis, dynamic testing, dependency review, and AI assisted code review.
• New submissions should face stronger security review.
• Existing plugins should be rescanned as models improve.
• Abandoned plugins should be flagged.
• High risk code patterns should trigger warnings or required fixes.

The WordPress plugin directory is not just a marketplace of ideas. It is part of the software supply chain for a large portion of the public Internet. It should be protected like critical infrastructure.

7. Clear End of Life Rules for Plugins and Themes

WordPress needs a stronger policy for abandoned plugins and themes.

If a plugin has not been updated in years, has unresolved security issues, or no longer has an active maintainer, WordPress should make that status more obvious.

Possible labels could include:

• actively maintained
• security maintained
• unmaintained
• abandoned
• removed for security reasons
• replacement recommended

These labels should appear inside the WordPress admin, not only on WordPress.org. A site owner should not discover that a plugin is abandoned only after the site is hacked.

8. Signed Updates for Plugins and Themes

WordPress Core has already taken important steps with signed updates. That same thinking should continue across the plugin and theme ecosystem. Every update delivered through WordPress.org should be cryptographically verifiable. Supply chain security is no longer optional.

If attackers can compromise developer accounts, update channels, build systems, or distribution paths, then plugin and theme updates themselves become an attack surface.

WordPress must make authenticity and integrity part of the update system by default.

9. A Security Event Log in Core

WordPress should include a built in security event log.

At minimum, Core should record:

• plugin installation
• plugin activation
• plugin deactivation
• plugin updates
• theme changes
• administrator creation
• role changes
• failed login spikes
• file editor usage
• critical option changes
• vulnerability notices
• emergency mitigations applied

This does not need to be complicated.

But when something goes wrong, site owners, hosts, and security professionals need a reliable record of what happened.

Right now, too much of that visibility depends on optional plugins.

This Is Not a Criticism of the WordPress Security Team

WordPress has benefited from many dedicated people who have quietly protected the project for years. This letter is not meant to dismiss that work. It is meant to say that the threat model, scale, speed, and the economics all changed in 2026.

A vulnerability that once required a skilled researcher may soon be found by a teenager experimenting with an AI coding assistant. A plugin that sat quietly for eight years may suddenly become the target of automated hacking tools. A weakness that once affected a few sites may be weaponized across the internet in literal hours. The WordPress security model must evolve accordingly.

A Request to WordPress.org

I am asking WordPress.org to make security a central product priority, not a side project, not a plugin recommendation, and not a responsibility quietly passed to site owners, web hosts, or commercial developers/vendors.

WordPress should not expect millions of users to assemble their own security model after installation. The platform itself needs to provide native awareness, clear warnings, safer updates, and meaningful protection when known vulnerabilities put sites at risk.

Before more interface experiments or nonessential initiatives, WordPress should publicly commit to a security roadmap for the AI era.

That roadmap should include:

• native vulnerability awareness
• vulnerability aware automatic updates
• rollback safe patching
• targeted virtual patching
• plugin and theme risk scoring
• abandoned plugin visibility
• stronger plugin directory scanning
• plugin permission transparency
• a Core security event log

WordPress made publishing available to everyone. Now it must make security available to everyone.

The next wave of attacks will not wait for every site owner to become a security expert. WordPress has to carry more of that burden itself.

If WordPress wants to remain the operating system of the open web, security can no longer be treated as something users put together from search recommendations after installation.

Security must become part of what WordPress is.

Respectfully,

Jim Walker
The Hack Repair Guy

2027 will be an exponentially challenging year for WordPress.

For most of WordPress’s history, building and maintaining the PHP code that powers plugins, themes, and WordPress itself required a real skill set. It required experience, patience, and a special kind of concentration.

That has changed.

In 2026, WordPress entered what I would call its unveiling year.

By unveiling, I mean that the barrier to both creating WordPress code and finding weaknesses in WordPress code has collapsed. Pretty much anyone with a basic education, a few dollars, and access to modern AI tools can now generate plugins, build themes, review PHP, test code paths, and discover vulnerabilities that previously required years of specialized experience.

That shift is not coming someday. It is already here.

This past week made that painfully clear. WordPress Core received an emergency security release after serious vulnerabilities were discovered and patched. Reporting around the issue indicated that AI tooling was involved in developing or validating the exploit chain. Whether one prompt or many, whether cheap or expensive, the larger point remains the same:

The old assumptions no longer hold. The ability to find exploitable PHP vulnerabilities is now available to everyone.

For years, WordPress security has depended on a mix of responsible disclosure, plugin developer responsiveness, managed hosting protections, security plugins, vulnerability databases, and the quiet assumption that finding exploitable bugs still required enough expertise to slow attackers down. That assumption is disappearing.

The Avalanche Problem

The greatest threat to WordPress is not only the next vulnerability in Core. It is the vast installed base of old plugins and themes.

WordPress has succeeded because it made publishing easy and extensibility nearly unlimited. That same success has created a security problem of historic scale.

There are millions of WordPress sites running plugins and themes written years ago, often by developers who have moved on, businesses that no longer exist, or maintainers who never expected their code to be reviewed by AI powered vulnerability testing tools.

Many of these plugins work fine. Many of them are useful. Many of them also contain insecure patterns that were common, unnoticed, or simply not understood at the time they were written.

In the past, those weaknesses were discovered slowly. A researcher found one. A botnet found another. A security company published a notice. A plugin developer released a patch, or did not. That pace is about to change.

As AI assisted code review and exploit generation become built into everyday tools, WordPress will face an avalanche of vulnerability reports, emergency patches, abandoned plugins, active exploitation campaigns, and confused site owners who have no idea which warnings matter and which actions are safe.

This is not a future where security remains a side concern. This is a future where security becomes the main feature WordPress must deliver.

WordPress Needs Security as a Native Product Feature

WordPress cannot depend forever on every site owner installing the right security plugin, choosing the right host, subscribing to the right vulnerability feed, understanding CVEs, reading patch notes, and manually deciding what to do when a plugin becomes dangerous. That model does not scale.

WordPress needs a native security layer that treats plugin and theme risk as a first class part of the platform.

In plain terms, WordPress Core should know when installed code is vulnerable, understand the likely severity, communicate clearly to the site owner, and take safe protective action when possible.

This does not mean WordPress needs to replace Patchstack, WPScan, Wordfence, hosts, researchers, or the existing security ecosystem.

It means WordPress needs to learn from them and bring the most essential protections into the platform itself.

What WordPress Core Should Build

1. A Native Vulnerability Intelligence Feed

WordPress should maintain or integrate a signed, trusted vulnerability feed for plugins, themes, and Core.

Every WordPress site should be able to answer basic questions without requiring a third party plugin:

• Is this installed plugin known to be vulnerable?
• Is the vulnerable version currently installed?
• Is there a safe update available?
• Is the plugin abandoned?
• Is exploitation active in the wild?
• Is this vulnerability remotely exploitable?
• Does it require authentication?
• Is there a temporary mitigation?

This information should appear directly in the WordPress admin, in Site Health, in Updates, and in a dedicated Security screen.

Site owners should not have to understand the difference between a theoretical vulnerability, a patched vulnerability, and an actively exploited vulnerability by reading scattered blog posts. WordPress should tell them plainly.

2. Vulnerability Aware Automatic Updates

WordPress already supports automatic updates, but security updates need a more intelligent model.

When a plugin or theme has a serious known vulnerability, WordPress should be able to prioritize that update differently from a routine feature release.

A modern security update system should include:

• automatic backup before high risk security updates
• compatibility checks where possible
• staged update attempts
• automatic rollback if the update breaks the site
• clear owner notification
• emergency update escalation for critical vulnerabilities
• host level coordination where available

If a vulnerability is being actively exploited, WordPress should not treat the update as just another available plugin update. It should treat it as a site safety event.

3. Temporary Virtual Patching

WordPress should explore a native virtual patching layer for known plugin and theme vulnerabilities. This is one of the most important ideas we should consider.

When a vulnerable plugin cannot be updated immediately, WordPress should be able to apply narrow, temporary protections that block known exploit patterns until the real patch is installed.

That could include protections around:

• dangerous request parameters
• unauthenticated AJAX actions
• vulnerable REST routes
• unsafe file upload paths
• known option changes
• privilege escalation patterns
• SQL injection signatures
• cross site scripting payloads

This does not need to become a full web application firewall inside Core.

But WordPress should be able to receive signed mitigation rules for known vulnerabilities and apply limited, targeted protection.

Patchstack has already shown that vulnerability intelligence and virtual patching can be productized. I'm not saying that WordPress should not copy a commercial service wholesale, but it should recognize the model as essential infrastructure.

4. A Plugin Permission Model

One of WordPress’s deepest security problems is that plugins generally receive enormous trust.

A simple plugin can often touch the database, create users, handle uploads, register REST routes, add AJAX actions, modify options, and execute powerful code.

WordPress needs a permission model that makes plugin capabilities visible and, over time, controllable. Site owners should be able to see what a plugin is allowed to do.

For example:

• Can this plugin create administrator users?
• Can it write files?
• Can it process uploads?
• Can it expose public REST API endpoints?
• Can it modify site options?
• Can it send email?
• Can it execute scheduled tasks?
• Can it access customer or user data?

This would be a major architectural challenge, but WordPress needs to start moving in this direction.

The plugin ecosystem was built for trust. The AI exploitation era requires boundaries.

5. Plugin Isolation and Restricted Execution

WordPress should begin developing ways to isolate risky plugin behavior. Not every plugin needs full access to everything.

Over time, WordPress could introduce restricted plugin modes, stronger sandboxing patterns, safer APIs, and warnings when plugins use dangerous functions or outdated practices. Even partial isolation would help.

A contact form plugin should not casually have the same practical power as a backup plugin, a membership plugin, or an ecommerce plugin. The current all or nothing model is too dangerous for the next phase of the web.

6. Continuous AI Assisted Directory Scanning

If AI tools can be used to find vulnerabilities by attackers, they should also be used continuously by WordPress.org. At a minimum:

• Every plugin and theme in the official directories should be scanned regularly using static analysis, dynamic testing, dependency review, and AI assisted code review.
• New submissions should face stronger security review.
• Existing plugins should be rescanned as models improve.
• Abandoned plugins should be flagged.
• High risk code patterns should trigger warnings or required fixes.

The WordPress plugin directory is not just a marketplace of ideas. It is part of the software supply chain for a large portion of the public Internet. It should be protected like critical infrastructure.

7. Clear End of Life Rules for Plugins and Themes

WordPress needs a stronger policy for abandoned plugins and themes.

If a plugin has not been updated in years, has unresolved security issues, or no longer has an active maintainer, WordPress should make that status more obvious.

Possible labels could include:

• actively maintained
• security maintained
• unmaintained
• abandoned
• removed for security reasons
• replacement recommended

These labels should appear inside the WordPress admin, not only on WordPress.org. A site owner should not discover that a plugin is abandoned only after the site is hacked.

8. Signed Updates for Plugins and Themes

WordPress Core has already taken important steps with signed updates. That same thinking should continue across the plugin and theme ecosystem. Every update delivered through WordPress.org should be cryptographically verifiable. Supply chain security is no longer optional.

If attackers can compromise developer accounts, update channels, build systems, or distribution paths, then plugin and theme updates themselves become an attack surface.

WordPress must make authenticity and integrity part of the update system by default.

9. A Security Event Log in Core

WordPress should include a built in security event log.

At minimum, Core should record:

• plugin installation
• plugin activation
• plugin deactivation
• plugin updates
• theme changes
• administrator creation
• role changes
• failed login spikes
• file editor usage
• critical option changes
• vulnerability notices
• emergency mitigations applied

This does not need to be complicated.

But when something goes wrong, site owners, hosts, and security professionals need a reliable record of what happened.

Right now, too much of that visibility depends on optional plugins.

This Is Not a Criticism of the WordPress Security Team

WordPress has benefited from many dedicated people who have quietly protected the project for years. This letter is not meant to dismiss that work. It is meant to say that the threat model, scale, speed, and the economics all changed in 2026.

A vulnerability that once required a skilled researcher may soon be found by a teenager experimenting with an AI coding assistant. A plugin that sat quietly for eight years may suddenly become the target of automated hacking tools. A weakness that once affected a few sites may be weaponized across the internet in literal hours. The WordPress security model must evolve accordingly.

A Request to WordPress.org

I am asking WordPress.org to make security a central product priority, not a side project, not a plugin recommendation, and not a responsibility quietly passed to site owners, web hosts, or commercial developers/vendors.

WordPress should not expect millions of users to assemble their own security model after installation. The platform itself needs to provide native awareness, clear warnings, safer updates, and meaningful protection when known vulnerabilities put sites at risk.

Before more interface experiments or nonessential initiatives, WordPress should publicly commit to a security roadmap for the AI era.

That roadmap should include:

• native vulnerability awareness
• vulnerability aware automatic updates
• rollback safe patching
• targeted virtual patching
• plugin and theme risk scoring
• abandoned plugin visibility
• stronger plugin directory scanning
• plugin permission transparency
• a Core security event log

WordPress made publishing available to everyone. Now it must make security available to everyone.

The next wave of attacks will not wait for every site owner to become a security expert. WordPress has to carry more of that burden itself.

If WordPress wants to remain the operating system of the open web, security can no longer be treated as something users put together from search recommendations after installation.

Security must become part of what WordPress is.

Respectfully,

Jim Walker
The Hack Repair Guy

🧠 The AI Mindset: Keep Your Hands on the Wheel

• Do use AI to accelerate your actual skills: Use it to do things you already know how to do, just faster. Think of it as a high-speed assistant, not a replacement for your brain.
• Don't rely on AI for things you don't understand: If you lack the fundamental knowledge to validate the output, you won't spot the errors, hallucinations, or massive security flaws. If you can't audit it, don't deploy it.
• Don't let AI give you unearned confidence: AI is world-class at sounding smart and completely confident, even when it is dead wrong or spewing unactionable fluff.

✅ The DOs: Best Practices for Safety & Control

Data & System Access

• Do verify your backups first: Before you let any local AI tools or agents anywhere near your machine or server, ensure you have backups that you have actually, successfully restored at least once. A backup is only as good as its restore test.
• Do keep backups completely isolated: Ensure your system backups live entirely off the main server or box and use completely separate, unlinked credentials. If the box gets compromised, your safety net shouldn't go down with it.
• Do use the "Policy of Least Privilege": Give AI a tightly scoped, restricted set of keys that can be easily rotated or revoked. Consider keeping a separate, locked-down account for your AI in your password manager.
• Do default to read-only access: Limit AI to read-only access for production databases and live environments. Only grant write access in isolated development or staging environments.
• Do implement staging, gates, and rollbacks: Always use a safety net—like version control for your code—so you can instantly roll back any destructive changes if things go sideways.

Operations & Workflows

• Do use a "human-in-the-loop" model: Let the AI draft the emails, logs, or code, but you must be the ultimate gatekeeper who reviews, validates, and officially signs off before anything is sent or executed.
• Do set hard financial budgets: Put strict spending limits and caps on your AI API accounts. A runaway background process or an infinite loop can drain thousands of dollars overnight if you aren't paying attention.
• Do go slow: Add permissions and system access one small notch at a time. If you don't fully understand the security risk of the next step, stop and learn before you click that button.

❌ The DON'Ts: Critical Mistakes to Avoid

• Don't run AI on "auto-mode" for critical tasks: Never let an autonomous AI agent make destructive changes or manage live, production environments without explicit human permission.
• Don't give AI write access to a production database: Letting an unsupervised AI touch a live database is an absolute recipe for accidental data deletion or corruption.
• Don't hand over your master/admin keys: Never give root-level credentials or master administrative access to an AI assistant. Keep the keys to the castle in human hands.
• Don't let AI process untrusted inputs blindly: Avoid letting AI read or parse untrusted data—like external emails, scrapable forms, or random user text—unless you deeply understand prompt injection attacks and have coded strict, bulletproof guardrails around them.
• Don't ship raw AI content or code: Avoid publishing "luck and prayers" software or generating masses of pure AI fluff. Without human filtering, tweaking, and real-world security auditing, the output lacks genuine value, safety, and soul.

Your thoughts on this guide?

We've built this new little utility I’m calling the "TVC.Net Secure Hosting Login Droplet for AI"

TVC.Net Secure Hosting Login Droplet for AI

The idea is simple:

A lot of people have website hosting login details, FTP over TLS/SSL access, or SSH access, but they do not want to keep passwords sitting around in plain text, buried in notes, or pasted into random scripts.

This droplet walks a person through setup step by step in plain English, securely saves the password to the local macOS Keychain, and creates a reusable login droplet tied to that hosting account.

What it does:

• asks friendly setup questions instead of expecting technical knowledge
• supports FTP over TLS/SSL and SSH
• stores the password in macOS Keychain, not inside the droplet file
• creates one droplet per login
• makes it easier for local AI tools to work with saved credentials more safely later

What I like about it is that it is aimed at real-world people, not just developers. If someone only has their hosting login info and does not really know FTP or SSH, the flow is designed to guide them through it without making them feel like they need a degree in computer science.

What does it do?

It is not trying to be a giant password vault. It is one droplet, one login, one job. That keeps it cleaner and safer.

Your thoughts?

We are still refining the user flow and wording, but the goal is straightforward:
help a person save hosting access more safely, then let trusted local AI workflows use that access later without hardcoding secrets into scripts or project files.

If anyone wants to see the setup flow, suggest wording improvements, or has ideas for the next step like guided upload/test actions, we’d love the feedback.

In case you are curious about the cPanel outage that occurred on July 8th, below is the follow-up sent to cPanel partners. Historical trivia at this point, but here it is:

"On July 8, we rolled out improvements to how we deliver critical security updates to cPanel & WHM servers. This temporarily overloaded our licensing service, which briefly prevented some servers from refreshing their license. If your server was affected, you may have experienced disrupted access between approximately 4:16 PM and 5:32 PM CT.

 We've since corrected the issue, and license operations have been back to normal as of July 8. No action is required; affected servers will automatically refresh their license status.

If you would prefer to also run a manual refresh, you can do so with:

/usr/local/cpanel/scripts/cpkeyclt

Repeated login attempts may have triggered cPHulk or other brute-force protections during the window. If this has occurred, please review recent blocks in those tools. Our Help Center article is available for full details.

We regret any disruption this may have caused and appreciate your patience. Our support team is available if you have further questions.

Best regards,
Your cPanel Team"

Google Search Console Platform Properties?

We've written this guide for our TVCNet client's, "What Are Google Search Console Platform Properties? (2026 Guide)"

Google Search Console now covers Instagram, TikTok, X & YouTube. See the exact search queries sending people to your posts — free, 10-minute setup.

Please post your comments or questions in this thread.

https://blog.tvcnet.com/google-search-console-platform-properties/

**To TVCNet suport:**
*Date: Saturday, July 4, 2026 at 9:29 AM*
I need a guide on how to upload a DNS record to this domain. Please help me with a guide.

**Reply back:**
*Date: Saturday, July 4, 2026 at 9:33 AM*
We can do better than that. Please send along your DNS update, and we'll take care of it for you.

To TVCNet suport:
Date: Saturday, July 4, 2026 at 9:29 AM
I need a guide on how to upload a DNS record to this domain. Please help me with a guide.

Reply back:
Date: Saturday, July 4, 2026 at 9:33 AM
We can do better than that. Please send along your DNS update, and we'll take care of it for you.

From our blog

Is the Golden Age of the “Blog-as-a-Business” Officially Over?

If you’ve noticed your Google search results looking completely different lately, you aren’t alone. A new four-year study by Daniel Stanica tracked 100 previously highly successful blogs from 2022 to 2026, and the results are a massive wake-up call for digital creators.

Link in comments 👉

* No bots allowed at TVCNet *

In case you hadn't heard, we offer many other advanced services that many hosts simply don't have the technical knowledge or ability to provide. Our rates are so low that you could very well upsell these services at margins of 100% to 300%.

___

- Basic web design.

Have a client with some update needs, and you just don't have the time to focus on it. We've got your back. $30.

- Advanced junk mail filtering.

Tired of junk mail, we got you covered. Twenty email accounts. $5.95/mo.

- Website hacked or need an in-depth security review on our server.

Just $79 (regularly $279).

- .com registrations and renewals.

$19.95/yr. Or transfer over for less at $17.95 for the first year.

- Personalized WordPress Management.

We do updates and backups and keep those hackers out! Just $5ish/mo. per WordPress.

Is your business worth the cost of a cup of coffee per week to keep it secure?

___

Please ask away if you have questions on any of these services.

Call Jim, (619) 479-6637