Designers, photographers, illustrators, and other creative professionals also have practical requirements. Staging makes it possible to test layout changes privately. Automatic backups protect client work, while collaboration tools can help freelancers and agencies manage several websites. Good support is also valuable when a technical problem interrupts a project or affects a live site.

This collection compares WordPress hosts based on the features that matter most to creatives. These include performance, media handling, storage, theme and plugin support, staging, backups, client management, and long term cost.

Some options are suited to a single portfolio, while others provide the tools needed to manage client websites or run a creative agency. The best choice depends on the type of work being presented and how much control the website owner needs.

Quick Recommendations

Each of these hosts suits a different type of creative website. WordPress.com offers the simplest overall package, while Kinsta and Pressable provide stronger tools for studios and client work. Cloudways gives experienced users more control, and Rocket.net is a good match for image heavy portfolios.

WordPress.com is the best choice for creatives who want managed hosting with little technical maintenance. Kinsta is better suited to established studios that place greater value on performance, staging, and developer tools. Pressable is worth considering when several client websites need to be built, tested, and managed from one account.

Cloudways offers more flexibility but requires greater technical confidence. Rocket.net offers managed performance and a built in CDN for visual websites with an international audience. SiteGround and Hostinger cost less at the start, although their renewal prices are considerably higher.

Prices shown are monthly equivalents based on the billing terms displayed by each provider.

What Creatives Should Look for in WordPress Hosting

Creative websites often contain large images, complex layouts, video, animation, and interactive features. These elements can place more pressure on hosting than a basic blog or small business website.

• Image and media performance: Look for server caching, CDN access, and enough storage for a growing media library. Image compression and support for WebP or AVIF can also help portfolio pages load faster.
• Theme and design tool support: The host should support custom themes and third party plugins. Designers using page builders, animation plugins, or Advanced Custom Fields may also benefit from higher PHP memory and stronger server resources.
• Staging and development tools: Staging allows design changes, theme updates, and new layouts to be tested privately. SFTP, SSH, WP CLI, Git, database access, and PHP controls are also useful for custom and client websites.
• Client and team management: Freelancers and agencies may need collaborator accounts, separate permissions, site cloning, and a central dashboard for managing several projects. Site transfer and billing handover tools can also simplify client delivery.
• Backups and site recovery: Automatic backups provide protection when an update, code change, or plugin conflict causes a problem. Check how often backups are created, how long they are stored, and whether the website can be restored with a single click.
• Pricing and renewal costs: Check the regular renewal rate rather than relying on the introductory price. Storage, traffic, staging, backups, email, and additional websites may depend on the plan, so the cheapest option is not always the best value.

Top WordPress Hosts for Designers & Creatives

1. Best Overall for Creatives: WordPress.com

WordPress.com is a good choice for creatives who want managed hosting without spending much time on server maintenance. Updates, security, backups, caching, and performance tools are handled for you, leaving designers to manage their website through a familiar WordPress dashboard.

The Business plan is the best fit for a professional portfolio or creative business. It includes 50GB of storage, a global CDN, staging, real time backups, and 250GB of separate VideoPress storage. Custom themes and third party plugins are supported, so designers are not limited to the themes and tools supplied. SFTP, SSH, WP CLI, Git commands, and GitHub deployments are also available for more advanced projects.

The main drawback is cost. Each website requires its own plan, which may not suit freelancers or agencies managing a large number of client sites. However, it remains a practical option for individual designers, photographers, illustrators, and creative businesses that want strong performance without dealing with the technical side of hosting.

• Recommended plan: Business.
• Best for: Professional portfolios and creative business websites.
• Key strength: Managed hosting with strong media and development tools.
• Main drawback: A separate plan is required for each website.

Read moreThe joy of art

Further Information:

2. Best for Creative Studios: Kinsta

Kinsta is well suited to established designers and creative studios that need dependable managed hosting for a professional portfolio, company website, or online store. Its platform handles caching, security, backups, and server maintenance, while the MyKinsta dashboard provides access to staging, analytics, redirects, and other WordPress tools.

Every plan includes a global CDN, automatic daily backups, free migrations, application performance monitoring, and malware removal. Designers can create a staging copy before changing a layout, installing a new plugin, or updating a custom theme. Site transfer and user access controls are also useful when a studio works with outside developers or needs to hand a project over to a client.

The main limitation for visual websites is storage. The entry plan includes 10GB, which may be restrictive for a large photography or video portfolio. Visitor, bandwidth, storage, and CDN limits can also lead to additional charges. Kinsta costs more than shared hosting, but its performance and management tools make it a strong option when the website supports an established creative business.

• Recommended plan: Single 20GB
• Best for: Established creative studios and professional portfolios
• Key strength: Managed performance and development tools
• Main drawback: Limited storage on the entry plan

Further Information:

3. Best for Freelance Designers: Cloudways

Cloudways is a good option for freelance designers who want more control than a typical managed WordPress plan provides. Websites run on cloud servers, with Cloudways supplying the dashboard, security tools, caching, backups, staging, and technical support.

The Flexible Micro plan includes 2GB of RAM, one virtual CPU, 50GB of storage, and 2TB of transfer bandwidth. It can host multiple WordPress installations, although every site shares the same server resources. Designers can create staging sites, clone existing projects, change the PHP version, and access files through SFTP or SSH. Monthly and hourly billing also make it possible to increase server resources as client work grows.

Cloudways requires more technical knowledge than WordPress.com or Kinsta. The dashboard includes server settings that may be unfamiliar to less experienced users. Cloudflare Enterprise is a paid addition on Flexible plans, while offsite backup storage is charged separately. Business email is not included. These extra costs need to be considered, but the flexible setup remains useful for freelancers managing several client websites.

• Recommended plan: Flexible Micro
• Best for: Freelance designers managing several websites
• Key strength: Flexible cloud resources and server controls
• Main drawback: More technical than fully managed alternatives

Further Information:

4. Best for Managing Client Websites: Pressable

Pressable is designed for WordPress professionals who build and maintain websites for clients. Its dashboard provides access to production, staging, and sandbox environments, giving designers separate spaces for development, testing, and client review.

The Signature plans include automatic backups, a global CDN, edge caching, free migrations, malware monitoring, and WordPress support. Granular collaborator permissions allow developers, designers, and clients to receive different levels of access. Pressable also provides site templates through DupliKits, which can save time when several projects use the same plugins, theme, or starting configuration.

The Signature 1 plan is suitable for a single client website, while higher plans support several installations. Storage and monthly visits are limited, and additional usage can result in extra charges. Pressable is also more expensive than placing several sites on one shared hosting account. However, its staging, sandbox, cloning, and collaboration tools make it a practical choice for designers who include hosting and maintenance in their client services.

• Recommended plan: Signature 1
• Best for: Designers building and maintaining client websites
• Key strength: Staging, sandbox, and collaboration tools
• Main drawback: Additional charges for storage and visitor overages

Further Information:

5. Best for Small Creative Studios: SiteGround

SiteGround is a practical choice for designers and small creative studios that need to host several websites without paying for each installation separately. Its custom Site Tools dashboard provides access to domains, email, backups, caching, security, and development tools.

The GrowBig plan supports unlimited websites and includes 50GB of storage, a CDN, daily backups, on demand backups, collaborators, and WordPress staging. Designers can test theme and layout changes before publishing them, while collaborator accounts allow clients or team members to access individual websites. Email hosting is included, which can reduce the need for another paid service.

The introductory price is low, but the renewal rate is much higher. SiteGround also uses shared hosting, so demanding WooCommerce sites or portfolios with heavy media libraries may require a more powerful plan. Even so, GrowBig offers a useful balance of storage, development tools, and multiple site support for small studios. Agencies needing Git, white label access, and priority support should consider the GoGeek plan.

• Recommended plan: GrowBig
• Best for: Small creative studios hosting several websites
• Key strength: Multiple websites with staging and collaboration tools
• Main drawback: A large price increase at renewal

Further Information:

6. Best for Portfolio Performance: Rocket.net

Rocket.net is a managed WordPress host built around Cloudflare Enterprise. Its global CDN caches website content closer to visitors, which can improve the delivery of portfolio images, fonts, scripts, and other visual assets to an international audience.

The Starter plan includes one WordPress website, unmetered visitors, 10GB of storage, 50GB of bandwidth, unlimited PHP workers, and a 99.99% uptime guarantee. Security features include a web application firewall, malware protection, and automatic updates. Daily backups are retained for 30 days, while free migrations are available for existing websites.

The 10GB storage allowance is the main concern for photographers and other creatives with large media libraries. Storage overages cost $2 per GB, so images should be resized and compressed before being uploaded. Video should usually be hosted through a separate video platform. Rocket.net is not the cheapest option for a single website, but its CDN, managed security, and straightforward pricing make it a strong choice when portfolio performance matters more than storage capacity.

• Recommended plan: Starter
• Best for: Portfolios serving visitors in several countries
• Key strength: Cloudflare Enterprise CDN included with every plan
• Main drawback: Only 10GB of storage on the Starter plan

Further Information:

7. Best Budget Option: Hostinger

Hostinger offers low cost managed WordPress hosting for designers creating a first portfolio, personal website, or small creative business site. Its custom dashboard handles WordPress installation, updates, backups, domains, email, and other common hosting tasks.

The Unlimited plan is the better choice for creative work. It includes 50GB of NVMe storage, daily backups, a CDN, and support for unlimited websites. One click staging allows designers to test theme updates and layout changes before publishing them. Email accounts, ecommerce support, and AI tools are also included, although some features are only available during the initial contract period.

The advertised monthly price requires payment for 48 months in advance. The plan renews at a much higher rate, so the full contract cost should be considered before signing up. Unlimited website claims are also governed by a fair usage policy, which means the account still has resource limits. Hostinger does not provide the same level of server control or advanced management tools found as other hosts, but it offers useful features for creatives working with a smaller budget.

• Recommended plan: Unlimited
• Best for: New portfolios and budget conscious creative businesses
• Key strength: Generous storage and multiple website support
• Main drawback: The lowest price requires a four year commitment

Further Information:

Performance Tips for Creative WordPress Websites

Good hosting can only do so much if images, video, fonts, and animation are not properly managed. The following steps can help keep a visual WordPress website responsive.

• Resize images to match the largest dimensions at which they will be displayed.
• Use WebP or AVIF files where browser support and image quality allow.
• Compress portfolio images before uploading them to WordPress.
• Use lazy loading so images outside the visible area are not loaded immediately.
• Serve images, scripts, and stylesheets through a CDN.
• Host long or high resolution videos through a dedicated video platform.
• Limit unnecessary font files, background videos, and complex animations.
• Test important portfolio pages on mobile devices and slower connections.
• Monitor storage and bandwidth use as the media library grows.

How the Hosts Were Assessed

Each host was assessed using its published plan details, feature documentation, pricing, and suitability for creative WordPress websites. The recommendations place particular weight on the following factors:

• Performance when serving images and other visual content.
• Storage, bandwidth, and visitor limits.
• Support for custom themes, plugins, and design tools.
• Staging, backups, site cloning, and recovery options.
• Developer access through SFTP, SSH, WP CLI, or Git.
• Tools for managing team members and client websites.
• Introductory pricing, renewal rates, and additional charges.

The final rankings reflect how useful each hosting service is for designers, photographers, freelancers, and creative studios. Pricing and plan limits were checked against the information published by each provider while this article was being prepared.

Final Verdict

WordPress.com is the best overall choice for designers and creatives who want managed hosting with strong media support. The Business plan includes 50GB of storage, separate VideoPress storage, staging, backups, a CDN, and developer tools. It is particularly well suited to professional portfolios and creative business websites.

Kinsta is a stronger option for established studios that value managed performance and detailed site controls. Pressable provides useful staging, sandbox, cloning, and collaboration features for designers maintaining client websites. Cloudways offers more server control and flexible resources, although it requires greater technical confidence.

SiteGround works well for small studios that want to host several websites from one account. Rocket.net is suited to portfolios with an international audience, but its storage limits need careful management. Hostinger is the most affordable option at the start and provides enough storage for a new portfolio, though its long contract and higher renewal rate should be considered.

Read more articles by Paul Andrew

The post Best WordPress Hosts for Designers & Creatives in 2026 appeared first on The NOKIA Blog.

SEO has always had a dash of mysticism to it. People have tried various tricks and techniques to improve rankings. Now, we’re faced with the challenge of pleasing AEO (Answer Engine Optimization). The goal is to get your content cited by AI models. That could be a search engine like Google. But it also includes ChatGPT, Claude, and other AI tools. When a user asks an AI model a question, you want to be a source of relevant information.

Much like SEO, AEO inspires debate about what providers are looking for in a website. Do we need to do anything drastic? Or are the fundamentals of adding metadata and structured content enough?

These are among the questions we’re trying to answer here today. We can’t promise perfect results, nor that best practices won’t change (that’s a given). But we can show you some tools and resources to help you on your journey.

The good news is that WordPress is a great platform for getting your site noticed by search engines. It already includes some basics, such as logical content structure and sitemaps. And its plugin ecosystem is full of high-quality tools. This includes options for improving your site’s AEO.

Let’s get started!

Why You Should Care About AEO

Traditional search engines are still an important piece of the puzzle for discovering content. However, people are also turning to AI tools for information within the context of a conversation. That differs quite a bit from how we’ve researched topics for the past 30 years or so.

For example, you might use Bing to find a list of WordPress e-commerce plugins. That’s great, but you still have to click through each relevant link to find what you’re looking for. You could, in theory, waste a lot of time researching plugins that aren’t a good fit for your project.

Compare that experience with using an AI tool like Gemini. You could ask for WordPress e-commerce plugins with specific features, such as subscriptions or shipping integrations. The AI model will provide a summary of plugins that match your request, complete with background information.

AI provides a succinct report that makes it easier for users to find links of interest. That’s important to every website owner, whether you’re a plumber or a tech publication. Making your site AEO-friendly is part of getting your content seen by the right people.

It’s also a different deal than the training bots that hog site resources. You can still block harmful bots while welcoming the legitimate ones.

Scan Your Site for AI Agent Readiness

What does your WordPress website need to be indexed by AI models? You may already be on the right track.

The basics of SEO, such as a robots.txt file and an XML sitemap, are must-haves. These items help direct bots to your content and tell them what to index, similar to how search engines use them. But there’s more to the story.

Cloudflare has a helpful scanning tool, Is Your Site Agent-Ready?, that analyzes your website’s structure. It looks for the following:

• The discoverability of your site, via robots.txt, sitemaps, link response headers, and DNS records.
• If your site makes content available in an AI-accessible format, such as Markdown.
• How your site manages bot access via robots.txt.
• Any agent skills your site may have, such as MCP.
• E-commerce protocols.

You’ll receive a report that details where you’re succeeding and where there’s room for improvement. We should note that some of the above may not apply to your website. For example, agent skills won’t be relevant unless you have AI agents on your website. You can also adjust the scan settings to focus only on the areas you care about.

As with all scanning tools (AI and otherwise), take the results with a grain of salt. However, they will provide some actionable advice. It’s up to you to determine what makes sense for your website.

Turn Your HTML Content Into Markdown

It may be a surprise, but HTML isn’t the best format for AI models to read. Instead, they prefer Markdown. This plain-text markup language is easier for bots (and humans) to understand. Elements like headings and lists can be identified without knowing code.

Markdown is also more efficient than HTML. Models don’t have to sift through lines of unnecessary code to access your content. That means fewer tokens, which is better for everyone.

WordPress doesn’t natively support Markdown output. However, WordPress.org recently added this capability via the experimental html-to-md plugin – and you can, too. It’s a simple way to make your site friendlier to AI models.

Install the plugin, activate it, and a <link> element will be added to each page’s header, pointing to the Markdown version. Your site’s visitors won’t know the difference, but AI models will.

LLM Markdown is a similar plugin, but with a twist. A settings page lets you enable or disable Markdown output for specific post types. Look for more plugins to hit the market as Markdown output becomes more commonplace.

Cloudflare users with paid plans also have access to a Markdown for Agents feature. It doesn’t require a plugin – simply turn it on in your account dashboard.

Helpful AEO Resources

Optimizing your WordPress website (or any website, for that matter) for AI agents isn’t as hard as you may think. The tools and tips above will help you determine and address your needs.

But AEO is a nascent subject. As such, expect things to change quickly. The following are some resources you can use to learn more and stay ahead of the game:

We hope you found this overview useful. Now that you have a better idea of what AEO is, it’s time for action!

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post How To Make Your WordPress Website AI-Friendly appeared first on The NOKIA Blog.

React Server Components don’t send HTML to your browser. They don’t send JSON either. When a server component renders, what actually travels over the wire is a custom streaming protocol called Flight. It’s a line-delimited format with its own type system, its own reference resolution, and its own rules for reconstructing executable behavior on the client.

Most React developers have never opened the Network tab and actually looked at a Flight payload. It looks like a mix of JSON fragments, dollar-sign-prefixed references, and module pointers that the React runtime silently reassembles into a live component tree. The framework handles it, so nobody questions it.

I’m not sure most teams have thought carefully about what that trust actually implies.

I started pulling apart the Flight protocol after CVE-2025-55182 dropped in December 2025. The security community called it React2Shell, and for good reason. It was a CVSS 10.0, unauthenticated remote code execution vulnerability sitting in the Flight deserialization layer. One crafted HTTP request to a Server Function endpoint, and an attacker had shell access. No credentials needed.

The federal Cybersecurity & Infrastructure Agency (CISA) added it to the Known Exploited Vulnerabilities catalog. Sysdig tied in-the-wild exploitation to North Korean state-sponsored actors deploying file-less implants through the Ethereum blockchain. That’s the kind of CVE that gets your attention.

After spending time in the source (mostly getOutlinedModel and getChunk, which is where the resolution logic that matters actually lives), I realized React2Shell wasn’t a one-off parsing bug. It was a symptom. Flight reconstructs executable references, lazy-loaded components, server RPC endpoints, and async state from a stream of text. That’s a deserialization system.

The attack surface extends well beyond a single missing hasOwnProperty check. This article covers how Flight works on the wire, where the deserialization sinks are, what attackers have already weaponized, and what’s still exposed.

This leads to a ranked, practical set of defenses for your own Server Components: schema validation on every Server Action, the server-only package, cross-site request forgery (CSRF) hardening beyond framework defaults, and an assessment of what the Taint API and Web Application Firewalls (WAFs) provide.

Table of Contents

Flight On The Wire

Open your browser’s Network tab on any Next.js App Router page and look for requests returning Content-Type: text/x-component. That’s Flight. It’s not a single JSON blob. It’s a streaming, line-delimited format where each line is a self-contained “row” that the client-side React runtime processes as it arrives over the connection.

Here’s what a simple Flight payload looks like in practice:

1:I["./src/components/ClientComponent.js",["chunks/main.js"],"default"]
2:J["$","article",null,{"children":"$1"}]
0:D{"name":"RootLayout","env":"Server"}

Row 1 is an import directive. It tells the client to load ClientComponent.js from the bundler’s chunk map. Row 2 is a JSON tree that constructs an <article> HTML element, and the "$1" inside children is a reference back to chunk 1 (the imported component). Row 0 defines the server execution context, marking this as a RootLayout running in the Server environment. Even in this tiny example, you can see the mix of structural data, module references, and cross-chunk pointers that makes Flight different from plain JSON.

The Row Format

Every row follows the same syntax: <ROW_ID>:<ROW_TAG><PAYLOAD>n. The row ID is a numeric identifier that other rows can reference. The tag is a single character (or short string) that tells the parser what kind of data follows. The payload is the actual content.

Here are the row tags I found while reading through the source:

So far, this might look like a benign structured data format with some custom tags, but the real complexity and attack surface live in the prefix system.

The $ Prefix System

This is where I started paying closer attention.

When the client-side parser encounters a string value starting with $, it doesn’t treat it as literal text. It intercepts the string, checks the prefix, and routes it through a type-specific resolution path. The parseModelString function in ReactFlightClient.js is where this happens. It’s essentially a big switch statement on the character after $.

Every other prefix resolves a chunk and gives you the parsed result. $@ hands you the raw internal Chunk object instead, the wrapper React uses to track resolution state, pending callbacks, and internal metadata (which is why it’s used for Promises and why exploits use it to get a mutable handle). Exposing framework plumbing through the protocol looks like a design mistake to me, though I’d be interested to hear the rationale if there is one.

And $: (property access) is the other critical prefix. It lets the protocol specify a path like $1:user:name, which tells the parser to resolve chunk 1, then access .user, then access .name on the result. That’s arbitrary property traversal driven by data in the stream. If you’ve spent any time auditing JavaScript for prototype pollution, that pattern should feel familiar.

This Is Not Just A Data Format

Flight is not JSON with extra steps. JSON gives you data. Flight gives you behavior. It reconstructs module references that trigger client-side code loading, creates server action endpoints the client can invoke as RPC calls, sets up Promise chains that the React runtime will await, and builds lazy-loaded component boundaries that execute on demand.

Whether React developers think of it that way or not, the mechanics look very similar to deserialization systems that have historically caused problems. The stream doesn’t just describe what the UI looks like. It instructs the client runtime on what code to load, what functions to call, and what to trust.

If you want to read the implementation yourself, fair warning: the chunk resolution path is miserable to follow. State transitions bounce between helper functions, and the naming obscures what the code is actually doing. I gave up on static reading and just set breakpoints. The key files are react-client/src/ReactFlightClient.js for the client-side parser (look for parseModelString, getChunk, reviveModel, and getOutlinedModel) and react-server/src/ReactFlightServer.js for the serialization side. The reply handler for Server Actions lives in react-server/src/ReactFlightReplyServer.js.

Why Flight Is A Deserialization Sink

The deserialization pattern is familiar: Java’s ObjectInputStream gave us ysoserial, Python’s pickle executes code on load(), PHP’s unserialize chains __wakeup and __destruct methods, and .NET’s BinaryFormatter was deprecated entirely.

The pattern: deserialize attacker-controlled input → invoke behavior during reconstruction → lose control of execution.

So JavaScript should be immune to this, right? JSON.parse() only produces plain data objects. No constructors fire. No magic methods run. You get back exactly what the JSON string describes, nothing more.

That’s true for raw JSON.parse(). But it stops being true the moment a framework wraps custom deserialization logic around it. And that’s exactly what Flight does.

Prototype Pollution

JavaScript uses prototype-based inheritance. Every object has a __proto__ link to its prototype, and property lookups walk up this chain. If an attacker injects __proto__ or constructor.prototype as a key during reconstruction, they modify the shared base prototypes that all objects inherit from. Downstream code reads attacker-controlled values without knowing.

Flight’s $: prefix performs property traversal on deserialized objects. The getOutlinedModel function walks colon-separated paths like $1:user:name by iterating through each segment and accessing it on the parent object. If those path segments include __proto__ or constructor, the traversal walks straight up the prototype chain. That’s not a theoretical risk. It’s exactly how React2Shell worked.

Duck Typing and Thenables

The V8 engine (and the JavaScript spec) treats any object with a .then property as a Thenable. When you await something, the runtime checks for .then and calls it if it exists. No class check. No internal slot verification. If .then is callable, it gets invoked.

Flight resolves chunks asynchronously. If an attacker constructs an object with a manipulated .then property and gets it into the chunk resolution pipeline, the runtime calls the attacker’s function during normal await behavior. The language semantics do the work.

I initially focused on $F because forging Server Action references seemed like the obvious attack surface. After tracing the resolution path, $: property traversal looked much more interesting. I also spent a few hours examining chunk status transitions (pending, blocked, resolved, errored) to see if you could force a chunk into an unexpected state, though that approach didn’t yield any results.

The Core Problem

These two risks converge in Flight because the protocol doesn’t just deserialize data. It deserializes behavior. The $ prefix system dictates which execution path the parser takes: $F creates a callable server endpoint, $L sets up lazy code loading, $B triggers a blob handler, $@ exposes internal framework state. The parser’s control flow is driven entirely by what’s in the stream.

If an attacker can influence the stream’s content, they control which functions the parser calls, which objects it constructs, and which internal state it exposes.

The Mechanics Of React2Shell

This is the CVE that proved the theory. CVE-2025-55182, nicknamed React2Shell, is a CVSS 10.0 unauthenticated remote code execution vulnerability in the Flight deserialization layer. One HTTP request, no login required, full shell access.

I want to walk through the entire gadget chain because understanding it reveals how much power the Flight protocol hands to an attacker who can control the stream.

The Root Cause

The vulnerability sits in getOutlinedModel, a function responsible for resolving deep property paths from the $: reference system. The instance used in the exploit chain lives in the server-side reply handling code (ReactFlightReplyServer.js). When the parser encounters a reference like $1:user:name, it splits on the colons and walks the path segment by segment. Here’s the vulnerable loop:

for (key = 1; key < reference.length; key++)
    parentObject = parentObject[reference[key]];

Two lines. No hasOwnProperty check. No validation that the property exists on the object itself rather than somewhere up the prototype chain. Just parentObject[reference[key]] and move on.

So an attacker supplies $1:__proto__:constructor:constructor, and the loop traverses from a plain JSON object up through Object.prototype to the Object constructor to the Function constructor. Function in JavaScript behaves like eval(). Function("arbitrary code")() executes.

No allowlist on property names. No check for __proto__. I searched reviveModel and the chunk initialization path for any filtering. Nothing.

The Gadget Chain

Getting from “I can reach the Function constructor” to “I have RCE” requires chaining several Flight protocol features together. The Resecurity write-up covers the full chain in detail; here’s the high-level sequence:

• Step 1: Prototype walk to Function.
  The $: path __proto__:constructor:constructor walks from any plain object to Object.prototype, then to the Object constructor, then to Function — JavaScript’s built-in eval() equivalent.
• Step 2: Raw chunk self-reference.
  $@0 returns the raw internal Chunk wrapper instead of its resolved value, giving the attacker a mutable handle on React’s internal state machine.
• Step 3: Thenable hijack.
  The attacker sets the chunk’s .then to Chunk.prototype.then, so React’s resolution pipeline treats the manipulated chunk as a legitimate Promise-like object and awaits it.
• Step 4: Context confusion.
  During the second deserialization pass, the payload overwrites _response._formData.get to point to the hijacked Function constructor and places the attacker’s shell command into _response._prefix.
• Step 5: Trigger via blob handler.
  $B0 invokes the blob handler, which internally calls response._formData.get(response._prefix + blobId) — now equivalent to Function("attacker_shell_command")(). That’s arbitrary code execution with whatever privileges the Node.js process has.

Each step uses a legitimate Flight protocol feature in a way the designers didn’t anticipate. There’s no single “broken” feature. The vulnerability emerges from how these features compose when an attacker controls the input.

Impact

The numbers on this one are stark:

• CVSS 10.0. The maximum possible score.
• Unauthenticated and pre-auth. No credentials needed — and the deserialization happens before any application-level auth checks run, so even endpoints behind login walls are exposed.
• Single HTTP request. One POST to a Server Function endpoint.
• Affected React 19.0.0, 19.1.0, 19.1.1, and 19.2.0, across react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack.
• CISA added it to the Known Exploited Vulnerabilities catalog within days.

What Happened In The Wild

Exploitation was immediate. Sysdig published research linking EtherRAT deployments to North Korean state-sponsored actors who weaponized the vulnerability within hours of disclosure. EtherRAT is a file-less implant that uses the Ethereum blockchain for command-and-control communication — a technique researchers call “EtherHiding” — making takedown nearly impossible because you can’t seize a blockchain.

Separately, Palo Alto’s Unit 42 documented a backdoor called KSwapDoor that masquerades as [kswapd1] on infected Linux systems, blending into process lists alongside the legitimate kswapd0 kernel swap daemon; their analysis confirms KSwapDoor uses RC4 encryption to protect its internal strings and configuration data, while C2 communications run over AES-256-CFB with Diffie-Hellman key exchange across a P2P mesh network. The speed and sophistication of these campaigns — state-sponsored actors deploying novel implants through a single unauthenticated HTTP request — underscores why a CVSS 10.0 in a deserialization layer demands immediate patching, not triage.

The Fix

The React team’s patch is clean and targeted. The core change caches the genuine hasOwnProperty method at module load time:

var hasOwnProperty = Object.prototype.hasOwnProperty;

Then every property check in the deserialization path uses .call() to invoke the cached reference:

hasOwnProperty.call(value, i);

Even if an attacker shadows hasOwnProperty on a malicious object, the check uses the original prototype method. The prototype chain traversal that powered the gadget chain is blocked. This fix shipped in React 19.0.1, 19.1.2, and 19.2.1.

The fix is correct. But reading through the patches, I noticed the React team hardened ownership checks while leaving the property traversal model intact. The $: prefix still walks colon-separated paths; it just validates each step now. I think exposing arbitrary property traversal through a network protocol was a design mistake, and the patch treats the symptom. If future bugs emerge, they’ll likely come from this same area.

The framework patch closes the known gadget chain, but it doesn’t change the fundamental dynamic: the Flight protocol still reconstructs behavior — executable references, module imports, RPC endpoints, async state — from a stream of text. That reconstruction happens before your application code runs, before your validation logic fires, before your auth middleware even sees the request. Relying solely on the framework to protect your Server Components means trusting that every edge case in a complex deserialization parser has been found and fixed. The defenses that follow are the practical steps you can take to limit the blast radius on your own.

Defenses, Ranked By Impact

Some of these close real attack paths. Others mostly make you feel safer than you are. I’ve ranked these from most-to-least impactful based on what I’ve seen in the vulnerability research. If you only have time for one change, start at the top.

1. Input Validation On Server Actions (Zod, Valibot)

This is the single most impactful thing you can do at the application level. The Flight deserializer processes raw, unvalidated network input before your code takes control. Strict schema validation is your primary defense against whatever the protocol reconstructs.

Put a schema validation call at the very top of every Server Action, before any business logic runs — and I mean before anything, including logging. If you log an argument before validating it, and that argument triggers the stringification bug from CVE-2025-55183, you’ve leaked source code before your validation even had a chance to run.

Zod and Valibot both work well for this. Validate types, shapes, string lengths, numeric bounds, and enumerated values. Reject anything that doesn’t match. Use .safeParse(), not .parse() — the throwing variant can surface internal error details in the response if you’re not careful with your error boundaries.

"use server"
import { z } from "zod"

const UpdateProfileSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  role: z.enum(["user", "editor"]),
})

export async function updateProfile(formData: FormData) {
  const parsed = UpdateProfileSchema.safeParse({
    name: formData.get("name"),
    email: formData.get("email"),
    role: formData.get("role"),
  })
  if (!parsed.success) return { error: "Invalid input" }
  // proceed with parsed.data, this is now the only shape
  // your business logic ever sees
}

One important nuance: If your Server Action accepts a plain object argument (not FormData), validate the whole argument — don’t destructure first and validate fields individually. Destructuring before validation means you’re already accessing properties on the unvalidated input, which is exactly the kind of operation the Flight deserializer can exploit.

"use server"
import { z } from "zod"

const CommentSchema = z.object({
  postId: z.string().uuid(),
  body: z.string().min(1).max(5000),
})

// Good: validate the raw argument first
export async function addComment(data: unknown) {
  const parsed = CommentSchema.safeParse(data)
  if (!parsed.success) return { error: "Invalid input" }
  await db.comments.create(parsed.data)
}

// Bad: destructuring before validation
export async function addCommentUnsafe(
  { postId, body }: { postId: string; body: string }
) {
  // by the time this runs, you've already accessed properties
  // on the deserialized input
  const parsed = CommentSchema.safeParse({ postId, body })
  // ...
}

If your Server Action doesn’t start with a schema parse, it’s a vulnerability waiting to happen. I’d argue this should be a lint rule — and if you’re running eslint-plugin-react, consider writing a custom rule that flags any "use server" export without a validation call in its first statement.

2. The server-only Package

The server-only package is straightforward and effective.

Import server-only at the top of any file that contains database credentials, raw API calls, internal business logic, or anything else that should never cross the server-client boundary. If a Client Component tries to import that file (directly or transitively), the build fails with a clear error.

import "server-only"
import { db } from "./database"

export async function getUser(id: string) {
  return db.query("SELECT * FROM users WHERE id = $1", [id])
}

The failure mode to watch for is barrel files. If you re-export a server-only function through an index.ts that also exports client-safe utilities, any Client Component importing from that barrel will pull in the server-only module transitively and break the build — or worse, if the barrel doesn’t include the server-only import itself, it may silently let server code through. Keep server-only modules in separate files with their own import paths.

// Don't do this: barrel re-export mixes boundaries
// src/utils/index.ts
export { getUser } from "./users"     // has "server-only"
export { formatDate } from "./dates"  // client-safe

// Do this: separate import paths
// Client Component imports from "src/utils/dates" directly
// Server Component imports from "src/utils/users" directly

It also won’t protect you from data leaking through return values. If a Server Component calls getUser() and passes the full user object (including passwordHash or internalRole) as props to a Client Component, that data rides the Flight stream to the browser. The server-only guard prevents the code from crossing the boundary, not the data the code returns. You must explicitly filter your return shapes.

3. CSRF Protections

After CVE-2026-27978, relying solely on Next.js’s built-in Origin vs. Host header check isn’t enough. The Origin: null bypass showed that framework-level CSRF protection has edge cases.

For state-changing Server Actions (anything that writes data, deletes records, or modifies permissions), layer your own protections on top of the framework’s defaults.

Cookie configuration.
Set SameSite=Strict or SameSite=Lax on session cookies. If you’re using next-auth or a custom session library, verify this is set explicitly — don’t rely on browser defaults, which vary.

// next.config.js or your auth configuration
cookies: {
  sessionToken: {
    name: "__session",
    options: {
      httpOnly: true,
      sameSite: "strict",
      secure: process.env.NODE_ENV === "production",
      path: "/",
    },
  },
}

Explicit CSRF tokens.
For high-value operations (password changes, role assignments, payment actions), generate a per-session CSRF token on the server, embed it in a hidden form field or custom header, and validate it in the Server Action before proceeding.

"use server"
import { cookies } from "next/headers"
import { validateCsrfToken } from "@/lib/csrf"

export async function deleteAccount(formData: FormData) {
  const token = formData.get("csrf_token") as string
  const sessionToken = (await cookies()).get("csrf_secret")?.value
  if (!validateCsrfToken(token, sessionToken)) {
    return { error: "Invalid request" }
  }
  // proceed with deletion
}

The allowedOrigins gotcha.
Never, under any circumstances, add 'null' to experimental.serverActions.allowedOrigins in your Next.js config (even if the officially advisory is more nuanced, saying “unless intentionally required and additionally protected”). That string literal matches Origin: null — the exact header that sandboxed iframes send — and it reopens the CVE-2026-27978 bypass. If you’re seeing CSRF failures from legitimate requests, the fix is to configure your reverse proxy to set the correct Origin and Host headers, not to weaken the validation.

// Never do this
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ["null"],  // reopens CSRF bypass
    },
  },
}

4. The hasOwnProperty Patch

I covered this in detail in the React2Shell section. The fix is correct, and it completely neutralizes the known gadget chain. It shipped fast, which I respect.

The action item here is to verify you’re actually running a patched version. The RCE fix landed in React 19.0.1, 19.1.2, and 19.2.1. Check your lockfile:

# npm
npm ls react react-dom react-server-dom-webpack

# pnpm
pnpm ls react react-dom react-server-dom-webpack

# yarn
yarn why react-server-dom-webpack

If you see 19.0.0, 19.1.0–19.1.1, or 19.2.0, you’re vulnerable to the RCE. Update immediately. And don’t stop there: the DoS fixes (CVE-2025-55184, CVE-2025-67779, CVE-2026-23864) require 19.0.4+, 19.1.5+, or 19.2.4+. If you updated after React2Shell and then stopped paying attention, you may still be running a version vulnerable to the DoS variants.

It’s a reactive patch, not a structural redesign.

Note: More on that in Where This Goes Next.

5. The Taint API

React’s taintObjectReference and taintUniqueValue functions register objects or strings with the runtime. If tainted data tries to pass through the Flight serializer, it throws an error. The idea is to prevent sensitive data — user records, API keys, tokens — from accidentally leaking into the client.

Here’s how it looks in practice:

import {
  experimental_taintObjectReference as taintObjectReference
} from "react"
import "server-only"

export async function getUserRecord(id: string) {
  const user = await db.users.findUnique({ where: { id } })
  taintObjectReference(
    "Do not pass the full user object to Client Components. " +
    "Select only the fields you need.",
    user
  )
  return user
}

If a Server Component passes the tainted user object as props to a Client Component, React throws it at serialization time with your custom error message. That’s genuinely useful as a development-time guardrail.

The catch — and it’s a significant one — is that taint tracks object references, not data content. Any derivation breaks the tracking:

const user = await getUserRecord(id)

// taint is lost. Spread creates a new object.
<ClientProfile user={{ ...user }} />

// taint is lost. Individual properties aren't tracked.
<ClientProfile token={user.apiToken} />

// taint is lost. Serialization round-trip creates new refs.
<ClientProfile user={JSON.parse(JSON.stringify(user))} />

// taint fires. Same object reference.
<ClientProfile user={user} />

taintUniqueValue works on specific strings (like API keys), but it’s also reference-based. If the same key value appears in a different variable, the taint doesn’t follow.

Think of taint as a development guardrail, not a security boundary. It catches honest mistakes: a developer accidentally passing a full user object to the client. It won’t stop an attacker who can influence what gets serialized, and it won’t survive routine data transformations that your own code performs. It’s a useful defense-in-depth layer, but shouldn’t be your primary boundary.

6. WAFs

Web Application Firewalls can add a detection layer for known attack patterns. They can inspect POST requests carrying the Next-Action header, block payloads containing constructor:constructor or __proto__ chains, and flag error responses containing E{"digest" patterns that indicate the server is leaking internal error details.

If you’re running a WAF, here are specific patterns worth adding:

# Block prototype pollution attempts in request bodies
Rule: body contains "__proto__" OR "constructor:constructor"
Action: BLOCK
Scope: POST requests with header "Next-Action"

# Flag potential Flight error leakage in responses
Rule: response body matches /E{"digest":"[^"]+"/
Action: LOG + ALERT
Scope: responses with Content-Type "text/x-component"

# Block excessively large Server Action payloads
Rule: Content-Length > 1MB for POST with "Next-Action" header
Action: BLOCK (mitigates CVE-2026-23864 zipbomb vector)

But attackers know about WAF inspection buffers, and they’re usually around 128KB. Prepend 130KB of padding before the malicious payload, and the WAF inspects the padding, finds nothing, and lets the request through. Chunked Transfer-Encoding tricks accomplish the same thing.

The failure mode is treating WAF coverage as a security boundary rather than a noise-reduction layer. WAFs catch automated scanners and low-effort attacks, and that has real value. But a motivated attacker will bypass them with padding or encoding tricks. The defenses that actually stop sophisticated attacks are the ones earlier in this list: validating input before it reaches your business logic, keeping sensitive code off the wire, and staying on patched versions.

What Came After React2Shell

React2Shell wasn’t the end of it. The security audits that followed the December 2025 disclosure shook out a series of related vulnerabilities in the same deserialization surface. None of them are as severe as the original RCE, but they’re worth tracking because some of them required multiple rounds of patching.

The DoS pair (CVE-2025-55184 and CVE-2025-67779) is a textbook example of why deserialization parsers are hard to patch correctly. The first fix shipped, researchers found edge cases it missed, and a second round was needed. CVE-2026-23864 added a third DoS vector through unbounded memory allocation rather than CPU exhaustion. (See the defenses section above for specific version checks.)

CVE-2025-55183 is the sneaky one. It’s a source code exposure bug that triggers when a Server Function calls JSON.stringify (or any implicit stringification) on one of its arguments. Developers do this constantly for logging, debugging, or error reporting.

The attacker sends a crafted argument that, when stringified, causes the deserialization parser to reflect the function’s own source code back in the response. Business logic, database queries, and any hardcoded secrets sitting in Server Action files become readable by anyone who can send an HTTP request.

CVE-2026-27978 is a different class of bug entirely. It’s a CSRF bypass in Next.js’s Server Action handling. Next.js validates that the Origin header matches the Host header to prevent cross-site request forgery. But when a request comes from a sandboxed <iframe>, the browser sends Origin: null.

The Next.js parser in action-handler.ts treated the string 'null' as a missing origin rather than an explicit cross-origin indicator. So an attacker could embed a form inside a sandboxed iframe, submit it, and invoke Server Actions using the victim’s authenticated session cookies. Fixed in Next.js 16.1.7.

What’s Still Exposed

The CVEs above have patches. But some of the risk is structural, baked into how Flight is designed to work.

Man-In-The-Middle (MITM) On The Flight Stream

If an attacker can sit between server and client (CDN compromise, cache poisoning, rogue proxy), modifying the Flight stream in transit looks feasible. The format is plain text with a predictable structure.

Assuming stream control, an attacker could alter $I (Import) rows to redirect component loading to a different module in the webpack chunk map. They could inject $F (Server Reference) tags to embed hidden RPC triggers in the rendered UI. They could modify D (Data) rows to change component props, and if the target component uses dangerouslySetInnerHTML, that’s a direct XSS vector.

Flight escapes $ prefixes in user-supplied strings to prevent data from being interpreted as protocol instructions. But that only applies to data flowing through the serializer. A MITM attacker writes raw protocol directly into the stream. The escaping doesn’t help.

Server Action Enumeration

Server Action IDs are obfuscated hashes generated at build time. They look random. But server-reference-manifest.json maps every action ID to its source implementation. A public manifest hands an attacker a complete API map. This exposure usually stems from misconfigured hosting, an exposed .next directory, or path traversal.

Known action IDs expose Server Actions to standard IDOR and parameter tampering attacks. An attacker can forge direct requests with manipulated arguments. Developers often trust these inputs blindly because they originate from React’s internal machinery. The architectural consequences of that misplaced trust will be the focus of my next piece.

Encrypted Closure Tampering

When a Server Action captures variables from its surrounding scope (closures), Next.js encrypts them before sending to the client. The key is in NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, AES with a base64-encoded key (16, 24, or 32 bytes). decryptActionBoundArgs handles decryption on each invocation.

By default, this key regenerates every build. But multi-server setups often use a static key. If an attacker gets file read access (path traversal, SSRF), they extract the key, decrypt the closure state, modify it (changing a userId, a role, a query parameter), and re-encrypt. The server accepts the forged closure as legitimate.

Supply Chain Activation via Module IDs

I haven’t demonstrated this end-to-end, but the theory is straightforward.

Flight references client components by module ID, something like ["360","static/chunks/app/page-7f3480.js"]. The bundler assigns these IDs at build time based on the module graph. A compromised npm package sitting in node_modules as a transitive dependency gets bundled into a chunk but never loaded because no component references it. Inert.

But if an attacker injects $I import references into the Flight stream (via MITM, cache poisoning, or server-side injection), the parser should load that dormant module. There may be chunk-level validation I’m not seeing. But if the module ID is valid and present in the manifest, I don’t see what stops it. The attack doesn’t require the package to be imported anywhere in your code. It just needs to exist in the bundle output.

This Has Happened Before

React Flight isn’t the first framework to invent a custom serialization format for server-client communication and then discover it’s an attack surface. And it won’t be the last.

Google Web Toolkit (GWT) used a custom RPC protocol to sync Java objects between browser and server. BishopFox demonstrated that attackers could manipulate the wire format to achieve arbitrary deserialization; GWT eventually disabled binary serialization entirely. It took years.

Java Server Faces (JSF) and ASP.NET both serialized ViewState to the client as a hidden form field. When cryptographic signing was weak or missing, attackers tampered with the serialized state and achieved remote code execution. Microsoft and Oracle patched it repeatedly. The underlying pattern kept resurfacing.

The pattern is always the same: a framework invents a custom wire format to move rich, stateful, sometimes executable data between server and client. The designers assume the server is the sole producer of that data and the client is a trusted consumer. Then someone demonstrates that the wire format can be manipulated in transit, or that the server can be tricked into deserializing attacker-controlled input. React Flight is the latest entry in this pattern. It is not an anomaly.

Where This Goes Next

The React Flight protocol solves a genuinely hard problem: streaming interactive component trees from server to client in a way that enables progressive hydration, async data loading, and server-driven code splitting. It works. I don’t want to lose sight of that.

But it works by serializing executable references, async state, module pointers, and RPC endpoints over a streaming text protocol, and then trusting the structure of that stream on both ends. The React team has patched the known gadgets. The hasOwnProperty fix is correct. The DoS fixes are in place. The source code exposure bug is closed.

I think exposing arbitrary property traversal and executable Thenable reconstruction through a network-facing protocol was a design mistake. $:, $@, and $B are powerful internal primitives that were reachable through a parser that didn’t validate ownership of the properties it traversed. One check was missing, and the result was CVSS 10.0.

As more frameworks adopt server-driven UI patterns, the industry is going to need stronger primitives than “the server is trusted”: cryptographic validation of serialized payloads, signed component trees, and content integrity checks on the Flight stream itself.

Hoping the parser handles every edge case hasn’t worked historically, and I don’t see why it would start working now.

The code is in react-client/src/ReactFlightClient.js. If you ship Server Components, read it. Know what your framework is trusting on your behalf.

(gg, yk)

The post Weaponizing And Defending The React Flight Protocol: Deserialization Sinks In RSCs appeared first on The NOKIA Blog.

WordPress is the ideal testing ground for AI tools. You can work with code, generate content, or discover new ways to manage your website. It could do wonders for your workflow.

However, you probably don’t want to experiment in a production environment. There’s always a chance that something will go wrong and affect users. It’s not a risk worth taking!

Thankfully, there’s a new option worth getting excited about. The recently released my.WordPress.net installs a copy of the content management system (CMS) directly in your browser. It’s completely private, but can connect with various AI providers. It’s the perfect place to get a feel for what you can do with AI inside WordPress.

Let’s take a quick tour of my.WordPress.net. We’ll install it (super easy), connect it to AI, and start experimenting.

Sample Project: Integrate AI Into a Local WordPress Install

Today’s project is dead simple. First, we’ll install WordPress in our browser. Then, we’ll add our ChatGPT API key to integrate with the AI model. Finally, we’ll run a few test prompts to explore AI-based site management. Oh, and we’re sure to have a few adventures along the way.

Here we go!

Step 1: Install WordPress in Your Browser

We don’t want to spoil any surprises, but you might be amazed at how easy it is to install WordPress in your web browser.

1. Visit my.WordPress.net.
2. Enter a name for your website when prompted.

That’s all there is to it! You could optionally import content from another WordPress site. But we’re starting from scratch.

Once installed, you’ll see a welcome screen.

Step 2: Install the AI Assistant App

Those familiar with WordPress might be confused by the use of the term “apps”. After all, the CMS is famous for its plugin ecosystem. Not to worry. This offshoot decided that “apps” was a more user-friendly word for beginners. Consider plugins and apps as interchangeable.

Regardless, our next task is to install the AI Assistant app. Once again, it will be quick and easy.

1. Click on the Apps menu (an icon with four squares) on the upper right of the screen.
2. Find “AI Assistant” on the list and click on it.

The AI Assistant will automatically be installed on your local site. You’ll be returned to the welcome screen after it’s finished.

Step 3: Connect With an AI Model

We have everything we need to connect WordPress with an AI model. Now, it’s time to choose a provider.

At the time of this writing, AI Assistant works with Anthropic (Claude), OpenAI (ChatGPT), or a local AI model via Ollama. More providers may be added in the future.

1. Click on the command menu at the top of the screen (the long bar with a “/” inside) and select Dashboard.
2. Navigate to Settings > AI Assistant inside the dashboard.
3. Choose an AI provider and enter your API key.
4. Choose a model from your AI provider (we used gpt-4o-2024-08-06).
5. Save the revised settings.

In our case, we grabbed a ChatGPT API key and entered it into the settings. For reference, this method requires purchasing API credits from OpenAI. This is separate from your regular ChatGPT account.

The AI Assistant app also provides some information on what various WordPress user roles can access. You can also choose to add an AI Assistant button on the front-end of your site, which is displayed to logged-in users.

Step 4: Experiment!

The only thing left to do is have some fun with AI inside WordPress. You’ll find the AI Assistant throughout the dashboard and, optionally, the front-end of your website.

1. Click the AI Assistant button at the top right of the dashboard.
2. Enter a prompt in the chat window and start working with AI.

Here are a few sample prompts to get you started:

Create the following new pages on my website: About Us, Services, Contact Us

What time zone is my website using?

Activate the Hello Dolly plugin.

ChatGPT handled each of these requests without hassle. However, it did install a second copy of the Hello Dolly plugin. We’ll chalk it up to an early bug.

Note that you may be asked to approve certain actions, like creating pages or installing plugins. It’s a safety measure and is worth reviewing before allowing AI to make changes.

An Easy Way To Try AI Inside WordPress

Perhaps our experiments weren’t earth-shattering, but that’s not the point. The idea is that AI can tell you a lot about your website and perform routine tasks. And my.WordPress.net provides a safe space to learn and play.

Even better, the process for installing WordPress and integrating an AI model couldn’t be easier. You can be up and running within a few minutes. Just note the potential cost of using Anthropic or OpenAI for this purpose. Be sure to check your spending limits so you don’t lose a small fortune.

All told, it’s a great way to discover how AI can help your workflow inside of WordPress. So, take some time and find what works for you!

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post Using my.WordPress.net to Experiment With AI appeared first on The NOKIA Blog.

Last week I had the honor of delivering a commencement speech at the University of Namur (uNamur) for their 2025 graduation ceremony.

Standing in front of freshly minted computer science graduates, I talked about the future of software development in the age of AI. My message to them was simple: AI will not make you obsolete. We’ve seen tools evolve over the decades, from punch cards to IDEs to AI-assisted coding, but the work remains yours, not the tool’s. The developers who will thrive are those who stay curious, think in systems, communicate with precision, and take ownership of what they build. The world needs more people with coding skills, not fewer. AI raises the bar on what we can accomplish, and that’s a good thing.

Now, let’s get into this week’s AWS news.

Headlines

Anthropic’s Claude Opus 4.7 is now available in Amazon Bedrock – Anthropic’s most intelligent Opus model is now available in Amazon Bedrock, with improved performance across coding, long-running agents, and professional knowledge work. Claude Opus 4.7 scores 64.3% on SWE-bench Pro and 87.6% on SWE-bench Verified, extending its lead in agentic coding with stronger long-horizon autonomy and complex code reasoning. It also does better on knowledge work tasks like document creation, financial analysis, and multi-step research.

The model runs on Bedrock’s next-generation inference engine with dynamic capacity allocation, adaptive thinking (letting Claude allocate thinking token budgets based on request complexity), and the full 1M token context window. It also adds high-resolution image support for better accuracy on charts, dense documents, and screen UIs. Claude Opus 4.7 is available at launch in US East (N. Virginia), Asia Pacific (Tokyo), Europe (Ireland), and Europe (Stockholm), with up to 10,000 requests per minute per account per Region.

AWS Interconnect is now generally available with a new option to simplify last-mile connectivity – AWS Interconnect brings two managed private connectivity capabilities to general availability. The first, AWS Interconnect – Multicloud, provides Layer 3 private connections between AWS VPCs and other cloud providers (Google Cloud available now, Azure and OCI coming later in 2026). Traffic flows over the AWS global backbone and the partner cloud’s private network, never over the public internet, with built-in MACsec encryption, multi-facility resiliency, and CloudWatch monitoring. AWS published the underlying specification on GitHub under Apache 2.0 so any cloud provider can become an Interconnect partner.

The second capability, AWS Interconnect – Last Mile, simplifies high-speed private connections from branch offices, data centers, and remote locations to AWS through existing network providers. It provisions 4 redundant connections across 2 physical locations automatically, configures BGP routing, activates MACsec encryption and Jumbo Frames by default, and offers bandwidth from 1 Gbps to 100 Gbps adjustable from the console without reprovisioning. Last Mile launches in US East (N. Virginia) with Lumen as the initial partner.

Last week’s launches

Here are some launches and updates from this past week that caught my attention:

• Amazon ECR pull through cache now supports referrer discovery and sync — ECR’s pull through cache now automatically discovers and syncs OCI referrers (image signatures, SBOMs, attestations) from upstream registries into your private repositories. This means end-to-end image signature verification and SBOM discovery workflows work without client-side workarounds.
• AWS Transform is now available in Kiro and VS Code — AWS Transform, the agentic migration and modernization factory, is now accessible via Kiro (as a Power) and VS Code (as an extension). You can run custom transformations for common patterns like Java/Python/Node.js version upgrades and AWS SDK migrations directly from your IDE, with job state shared across the web console, CLI, and IDE.
• Aurora DSQL launches connector for PHP — A new Aurora DSQL Connector for PHP (PDO_PGSQL) simplifies building PHP applications on Aurora DSQL by automatically generating IAM tokens, handling SSL configuration, managing connection pooling, and providing opt-in optimistic concurrency control retry with exponential backoff.
• Amazon Q supports document-level access controls for Google Drive — Amazon Q now enforces document-level access controls for Google Drive knowledge bases, combining indexed ACL replication for fast pre-retrieval filtering with real-time permission checks against Google Drive at query time.
• AWS Secrets Manager now supports hybrid post-quantum TLS — Secrets Manager now supports hybrid post-quantum key exchange using ML-KEM to protect secrets against both current and future quantum computing threats. This is automatically enabled in Secrets Manager Agent 2.0.0+, Lambda Extension v19+, and the CSI Driver 2.0.0+.
• Amazon EC2 C8in and C8ib instances are now generally available — Powered by custom 6th-gen Intel Xeon Scalable processors and 6th-gen AWS Nitro cards, these instances deliver up to 43% higher performance over C6in. C8in offers 600 Gbps network bandwidth (highest among enhanced networking EC2 instances), while C8ib delivers up to 300 Gbps EBS bandwidth (highest among non-accelerated compute instances), scaling up to 384 vCPUs.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news

Here are some additional posts and resources that you might find interesting:

• Navigating enterprise networking challenges with Amazon EKS Auto Mode — This post explains how EKS Auto Mode automates Kubernetes networking infrastructure including VPC CNI configuration, load balancer provisioning, and DNS management, reducing operational overhead while preserving enterprise security controls.
• Introducing granular cost attribution for Amazon Bedrock — My colleague Micah talked about this feature last week already, but the blog post came out after last week’s roundup. Amazon Bedrock now automatically attributes inference costs to the specific IAM principal that made each API call, with results flowing into AWS Cost and Usage Reports (CUR 2.0). You can aggregate costs by team, project, or cost center using IAM principal tags and session tags.
• Accelerate development workflows with Amazon EBS Volume Clones — EBS Volume Clones let you create instant, point-in-time copies of EBS volumes that are immediately usable without waiting for data transfer. The post highlights use cases including dev/test environment refreshes, disaster recovery testing, and CI/CD pipeline acceleration.
• Modernize VB6 applications at scale with AWS Transform Custom — A walkthrough of using AWS Transform Custom’s agentic AI capabilities to convert legacy Visual Basic 6.0 applications to modern C# ASP.NET Core web applications, addressing challenges like COM dependencies, ADO-to-Entity Framework migration, and VB6 forms-to-Blazor UI conversion.
• Migrating and decomposing APIs with zero-downtime using CloudFront — A zero-downtime API migration strategy using CloudFront Functions with CloudFront KeyValueStore for intelligent, user-aware traffic routing based on the Strangler Fig pattern. This is similar to what AWS Migration Hub Refactor Spaces offers, but implemented with just CloudFront and edge functions.

Upcoming AWS events

Check your calendar and sign up for upcoming AWS events:

• AWS Events — Browse upcoming AWS-led in-person and virtual events, startup events, and developer-focused events near you.
• AWS Power Hour — Weekly live training sessions on Twitch covering various AWS topics.
• Community.aws — Find community-led events, meetups, and user groups in your area.

That’s all for this week. Check back next Monday for another Weekly Roundup!

— seb

The post AWS Weekly Roundup: Claude Opus 4.7 in Amazon Bedrock, AWS Interconnect GA, and more (April 20, 2026) appeared first on The NOKIA Blog.

Every host in this collection meets the needs of WordPress bloggers. They all offer managed WordPress hosting, built-in caching, daily backups, strong security, and easy-to-use dashboards.

Each provider answered a series of blogger-related questions (see the questions at the bottom of this page) that cover performance, pricing, migrations, uptime, user-friendliness, and many more features. So, this isn’t a review of personal experiences, as each host is ranked based on their answers and the needs of WordPress bloggers.

Pricing changes over time, so picking a host should start with features, not price. Some plans cost less but limit traffic or storage, while others charge more but include unlimited traffic or premium support. Bloggers should assess their needs first and then compare costs.

Whether running a small personal blog or a growing content site, the right host makes managing WordPress easier, keeps visitors coming back, and gives you the peace of mind to write your content without worrying about your WordPress installation.

Our Rating: 9.9/10

WordPress.com is a managed hosting platform owned by Automattic, the company behind the development of the WordPress.org open-source CMS. Unlike self-hosted WordPress.org sites, WordPress.com provides a fully managed environment, handling security, performance, and updates for you.

All hosting plans include automatic WordPress updates, built-in security, 24/7 customer support, and a custom, easy-to-use dashboard for site management. WordPress.com’s business plans start at $2.75 per month, and a 14-day money-back guarantee is available.

WordPress.com gives you a fully managed WordPress experience supported by the same team that maintains the open-source software. They’re perfect for bloggers.

Read morePassion & work

Learn more about WordPress.com

Our Rating: 9.8/10

Hostinger offers various hosting plans, including their Premium plan, with a 30-day money-back guarantee.

All Hostinger plans include automatic WordPress updates, built-in caching, free SSL certificates, malware scanning, DDoS protection, and 24/7 support.

Free automatic blog migrations are available, and domain registration is free for the first year. One-click WordPress installation and their custom dashboard will help to simplify site management.

Read moreThe joy of art

Learn more about Hostinger

Our Rating: 9.8/10

Bluehost offers both managed and shared hosting options for bloggers and website owners. The basic plan supports ten websites with 10GB of SSD storage. They also have a 30-day money-back guarantee.

They have a free site migration tool, and all plans include automatic WordPress updates, built-in caching, malware scanning, DDoS protection, and free SSL certificates.

Learn more about Bluehost

Our Rating: 9.8/10

Pressable offers fully managed hosting for WordPress bloggers. The Personal plan supports one site, 20GB of storage, and 30,000 monthly visits. A 30-day money-back guarantee is also available.

Automatic WordPress updates, daily backups, and free SSL certificates are included. Malware scanning, hack recovery assistance, a staging environment, one-click WordPress installation, and free site migrations are just some of the other features of Pressable.

Learn more about Pressable

Our Rating: 9.7/10

Cloudways offers managed WordPress hosting with a pay-as-you-go pricing model. The DigitalOcean Standard – 1GB plan is a good choice for bloggers. A free trial is available without a credit card.

The custom Cloudways dashboard replaces cPanel and includes one-click WordPress installation, automatic updates, database optimization tools, built-in caching, and a staging environment.

Learn more about Cloudways

Get 30% Off All Cloudways Plans Using Promo Code SPECKY30

Our Rating: 9.7/10

SiteGround offers hosting plans designed for single-site WordPress bloggers. Their StartUp plan allows for one website, which includes 10GB of storage and approximately 10,000 monthly visits. They offer a 30-day money-back guarantee.

Automatic WordPress updates, daily backups, free SSL certificates, free automated migrations, and built-in caching are included. A content delivery network (CDN) is available to improve loading times worldwide.

You can get in touch with their support at any time via chat, phone, and ticketing. The team specializes in WordPress and responds quickly to issues.

Learn more about SiteGround

Our Rating: 9.7/10

Kinsta provides high-performance hosting built on the Google Cloud Platform. The Single 35k plan supports one site, 35,000 monthly visits, 10GB of storage, and 125GB of CDN usage.

The MyKinsta dashboard offers a custom control panel for easier site management. Their features include automatic WordPress updates, one-click installation, daily backups, free SSL certificates, a staging environment, built-in caching, and a CDN with 260+ locations.

Our Rating: 9.6/10

WP Engine offers managed WordPress hosting to bloggers. The Startup plan is perfect for bloggers with a single website. It allows 25,000 monthly visits, 10GB storage, and 75GB bandwidth.

All plans include automatic WordPress updates, daily and on-demand backups, free SSL certificates, and a staging environment for testing changes. Users have a custom user portal for site management.

WP Engine focuses on delivering a secure and optimized environment for WordPress sites. A 60-day money-back guarantee is available for new customers.

Learn more about WP Engine

Our Rating: 9.6/10

HostPapa offers managed WordPress services with shared hosting options also available. The WP Starter plan supports two websites, 100GB of storage, unlimited bandwidth, and 100 email accounts.

Hosting includes free website migrations, automatic WordPress updates, one-click WordPress installation, free SSL certificates, daily backups, and built-in caching.

Learn more about HostPapa

Our Rating: 9.5/10

Rocket.net offers high-performance hosting with a focus on security and speed. The Starter Plan supports one site, 250,000 monthly visits, and 10GB of storage.

Hosting includes automatic WordPress updates, built-in caching, a global CDN, a staging environment, free SSL certificates, and daily backups with easy restore options.

Learn more about Rocket.net

WordPress Blog Hosting Comparison Table

Read more articles by Paul Andrew

The post The 10 Best WordPress Hosts for Bloggers in 2026 appeared first on The NOKIA Blog.

Earlier this year in May, we announced the general availability of AWS Transform for .NET, the first agentic AI service for modernizing .NET applications at scale. During the early adoption period of the service, we received valuable feedback indicating that, in addition to .NET application modernization, you would like to modernize SQL Server and legacy UI frameworks. Your applications typically follow a three-tier architecture—presentation tier, application tier, and database tier—and you need a comprehensive solution that can transform all of these tiers in a coordinated way.

Today, based on your feedback, we’re excited to announce AWS Transform for full-stack Windows modernization, to offload complex, tedious modernization work across the Windows application stack. You can now identify application and database dependencies and modernize them in an orchestrated way through a centralized experience.

AWS Transform accelerates full-stack Windows modernization by up to five times across application, UI, database, and deployment layers. Along with porting .NET Framework applications to cross-platform .NET, it migrates SQL Server databases to Amazon Aurora PostgreSQL-Compatible Edition with intelligent stored procedure conversion and dependent application code refactoring. For validation and testing, AWS Transform deploys applications to Amazon Elastic Compute Cloud (Amazon EC2) Linux or Amazon Elastic Container Service (Amazon ECS), and provides customizable AWS CloudFormation templates and deployment configurations for production use. AWS Transform has also added capabilities to modernize ASP.NET Web Forms UI to Blazor.

There is much to explore, so in this post I’ll provide the first look at AWS Transform for full-stack Windows modernization capabilities across all layers.

Create a full-stack Windows modernization transformation job

AWS Transform connects to your source code repositories and database servers, analyzes application and database dependencies, creates modernization waves, and orchestrates full-stack transformations for each wave.

To get started with AWS Transform, I first complete the onboarding steps outlined in the getting started with AWS Transform user guide. After onboarding, I sign in to the AWS Transform console using my credentials and create a job for full-stack Windows modernization.

After creating the job, I complete the prerequisites. Then, I configure the database connector for AWS Transform to securely access SQL Server databases running on Amazon EC2 and Amazon Relational Database Service (Amazon RDS). The connector can connect to multiple databases within the same SQL Server instance.

Next, I set up a connector to connect to my source code repositories.

Furthermore, I have the option to choose if I would like AWS Transform to deploy the transformed applications. I choose Yes and provide the target AWS account ID and AWS Region for deploying the applications. The deployment option can be configured later as well.

After the connectors are set up, AWS Transform connects to the resources and runs the validation to verify IAM roles, network settings, and related AWS resources.

After the successful validation, AWS Transform discovers databases and their associated source code repositories. It identifies dependencies between databases and applications to create waves for transforming related components together. Based on this analysis, AWS Transform creates a wave-based transformation plan.

Assessing database and dependent applications

For the assessment, I review the databases and source code repositories discovered by AWS Transform and choose the appropriate branches for code repositories. AWS Transform scans these databases and source code repositories, then presents a list of databases along with their dependent .NET applications and transformation complexity.

I choose the target databases and repositories for modernization. AWS Transform analyzes these selections and generates a comprehensive SQL Modernization Assessment Report with a detailed wave plan. I download the report to review the proposed modernization plan. The report includes an executive summary, wave plan, dependencies between databases and code repositories, and complexity analysis.

Wave transformation at scale

The wave plan generated by AWS Transform consists of four steps for each wave. First, it converts the SQL Server schema to PostgreSQL. Second, it migrates the data. Third, it transforms the dependent .NET application code to make it PostgreSQL compatible. Finally, it deploys the application for testing.

Before converting the SQL Server schema, I can either create a new PostgreSQL database or choose an existing one as the target database.

After I choose the source and target databases, AWS Transform generates conversion reports for my review. AWS Transform converts the SQL Server schema to PostgreSQL-compatible structures, including tables, indexes, constraints, and stored procedures.

For any schema that AWS Transform can’t automatically convert, I can manually address them in the AWS Database Migration Service (AWS DMS) console. Alternatively, I can fix them in my preferred SQL editor and update the target database instance.

After completing schema conversion, I have the option to proceed with data migration, which is an optional step. AWS Transform uses AWS DMS to migrate data from my SQL Server instance to the PostgreSQL database instance. I can choose to perform data migration later, after completing all transformations, or work with test data by loading it into my target database.

The next step is code transformation. I specify a target branch for AWS Transform to upload the transformed code artifacts. AWS Transform updates the codebase to make the application compatible with the converted PostgreSQL database.

With this release, AWS Transform for full-stack Windows modernization supports only codebases in .NET 6 or later. For codebases in .NET Framework 3.1+, I first use AWS Transform for .NET to port them to cross-platform .NET. I’ll expand on this in a following section.

After the conversion is completed, I can view the source and target branches along with their code transformation status. I can also download and review the transformation report.

Modernizing .NET Framework applications with UI layer

One major feature we’re releasing today is the modernization of UI frameworks from ASP.NET Web Forms to Blazor. This is added to existing support for modernizing model-view-controller (MVC) Razor views to ASP.NET Core Razor views.

As mentioned previously, if I have a .NET application in legacy .NET Framework, then I continue using AWS Transform for .NET to port it to cross-platform .NET. For legacy applications with UIs built on ASP.NET Web Forms, AWS Transform now modernizes the UI layer to Blazor along with porting the backend code.

AWS Transform for .NET converts ASP.NET Web Forms projects to Blazor on ASP.NET Core, facilitating the migration of ASP.NET websites to Linux. The UI modernization feature is enabled by default in AWS Transform for .NET on both the AWS Transform web console and Visual Studio extension.

During the modernization process, AWS Transform handles the conversion of ASPX pages, ASCX custom controls, and code-behind files, implementing them as server-side Blazor components rather than web assembly. The following project and file changes are made during the transformation:

Other new features in AWS Transform for .NET

Along with UI porting, AWS Transform for .NET has added support for more transformation capabilities and enhanced developer experience. These new features include the following:

• Port to .NET 10 and .NET Standard – AWS Transform now supports porting to .NET 10, the latest Long-Term Support (LTS) release, which was released on November 11, 2025. It also supports porting class libraries to .NET Standard, a formal specification for a set of APIs that are common across all .NET implementations. Furthermore, AWS Transform is now available with AWS Toolkit for Visual Studio 2026.
• Editable transformation report – After the assessment is complete, you can now view and customize the transformation plan based on your specific requirements and preferences. For example, you can update package replacement details.
• Real-time transformation updates with estimated remaining time – Depending on the size and complexity of the codebase, AWS Transform can take some time to complete the porting. You can now track transformation updates in real-time along with the estimated remaining time.
• Next steps markdown – After the transformation is complete, AWS Transform now generates a next steps markdown file with the remaining tasks to complete the porting. You can use this as a revised plan to repeat the transformation with AWS Transform or use AI code-companions to complete the porting.

Things to know

Some more things to know are:

• AWS Regions – AWS Transform for full-stack Windows modernization is generally available today in the US East (N. Virginia) Region. For Regional availability and future roadmap, visit the AWS Capabilities by Region.
• Pricing – Currently, there is no added charge for Windows modernization features of AWS Transform. Any resources you create or continue to use in your AWS account using the output of AWS Transform are billed according to their standard pricing. For limits and quotas, refer to the AWS Transform User Guide.
• SQL Server versions supported – AWS Transform supports the transformation of SQL Server versions from 2008 R2 through 2022, including all editions (Express, Standard, and Enterprise). SQL Server must be hosted on Amazon RDS or Amazon EC2 in the same Region as AWS Transform.
• Entity Framework versions supported – AWS Transform supports the modernization of Entity Framework versions 6.3 through 6.5 and Entity Framework Core 1.0 through 8.0.
• Getting started – To get started, visit AWS Transform for full-stack Windows modernization User Guide.

– Prasad

The post AWS Transform announces full-stack Windows modernization capabilities appeared first on The NOKIA Blog.