Am I affected? What do I do?

If you only read one section, read this one.

• On Xojo Cloud (Web 1 or Web 2)? You’re covered. Nothing to do.
• Using Lifeboat? Update Lifeboat and redeploy.
• Self-hosted behind Apache or Nginx? Drop in the filtering rule below. If you’re on Web 2, also upgrade to 2026r1.2 if possible.
• Self-hosted with the Xojo app exposed directly? On Web 2, upgrade to 2026r1.2 if possible, otherwise put a reverse proxy in front. On Web 1, put a reverse proxy in front (which is what we’d recommend either way).

The full details follow.

Timeline

• Thursday, the 23rd. A public issue and a private message landed on the same day, both pointing at the same bug.
• Thursday through Monday. We tracked down the root cause, wrote the fix, and tested it.
• Tuesday, the 28th. 2026r1.2 shipped with the patch.
• Wednesday, the 29th. Xojo Cloud patched at the platform level.

Under a week from the report to a patched release, with the platform-level mitigation following the next day.

What Happened

A request with a malformed percent-encoded sequence in a query parameter could crash a running Xojo Web app. The smallest reproducer is something like ?x=%. That’s a % not followed by two hex digits, which is invalid percent-encoding and isn’t decodable.

The bug lives in DecodeURLComponent. When the method ran into invalid input, it raised an exception instead of handling the input gracefully. Because the framework calls this method while parsing incoming requests, anyone could crash a web app by sending a single malformed URL. No authentication, no special headers, no payload. Just a bad query string.

A few things worth being upfront about:

• The bug has probably been there since DecodeURLComponent was introduced. Every Xojo release that ships the method might be affected.
• Both Web 1 and Web 2 are known to be affected. The Web framework has been calling this method on incoming requests across both generations.
• It’s not just a Web problem. DecodeURLComponent is a general-purpose method, and the same crash can happen in Desktop and other project types if you call it on attacker-controlled input. Web is the obvious target because requests arrive from the network, but the underlying issue isn’t Web-specific.

The Fix

In 2026r1.2, DecodeURLComponent no longer crashes on invalid input. Instead, it returns an empty String when the input contains a malformed percent-encoded sequence.

We thought about a few approaches and went with this one on purpose, for being consistent with the other sanity checks we do on this method. An empty return value lets existing code keep running rather than letting an exception bubble up through request handling, which is what you want from a method that’s frequently called on untrusted input. If your code already wraps DecodeURLComponent with its own validation, the new behavior gives you a clean signal to act on (an empty result) instead of an exception to catch.

Xojo 2026r1.2 is the only release with the fix. Web 1 won’t be getting a backported patch. What that means in practice is covered below.

What Xojo has already done for you

Xojo Cloud has been patched at the platform level. As of Wednesday 29th, Xojo Cloud rejects requests with malformed percent-encoding before they ever reach your app, returning a 400 Bad Request from the front-end web server. This protection doesn’t care which Xojo version your app was built with, and it covers Web 1 and Web 2 the same way.

If your app runs on Xojo Cloud, you don’t need to redeploy, upgrade, or change anything. We rolled this out specifically so that users who can’t upgrade right away are covered, including Web 1 users who can’t upgrade to a fixed version at all.

What you should do

The right move depends on which Web version you’re on and where your app runs.

If you’re on Web 2

Upgrade to 2026r1.2 and redeploy if you can. That’s the cleanest fix and it addresses the issue at the source.

We know “just upgrade” isn’t always realistic. You might be on an older version because your license has expired, because a third-party plugin you rely on hasn’t caught up yet, because a newer Xojo release introduced a regression you can’t ship around, or for any number of other reasons. If that’s you, the hosting-based mitigations below will protect your app in the meantime, and they work regardless of which Xojo version you built with.

If you’re on Web 1

There’s no Xojo release that patches DecodeURLComponent for Web 1, so the fix has to live outside your app. The good news is that if you follow Xojo’s standard hosting recommendations, you’re fully covered against this specific issue:

• Stay on Xojo Cloud. You’re already protected.
• Use Lifeboat. Tim Parnell shipped a Lifeboat update that catches malformed percent-encoding before it reaches your app. Update Lifeboat and redeploy.
• Run behind Apache or Nginx with the rules in the next section.

Separately, and on a longer horizon: Web 1 isn’t receiving framework patches anymore in general, so if you’re still on it, this is a reasonable moment to start thinking about a migration to Web 2. That’s a much bigger conversation than this post, but worth flagging.

Hosting-level mitigations

These rules reject malformed percent-encoded URLs at the web server, before the request reaches your Xojo app at all. They work for Web 1 and Web 2, and they don’t depend on the Xojo version you built with.

Apache:

# Reject malformed percent-encoding in the URI.
RewriteCond %{THE_REQUEST} %(?![0-9A-Fa-f]{2})
RewriteRule .* - [R=400,L]

Nginx:

# Reject malformed percent-encoding in the URI.
if ($request_uri ~ "%(?![0-9A-Fa-f]{2})") {
  return 400;
}

Reload your web server after updating the config (apachectl graceful or nginx -s reload) and check that a request like https://yourapp.example.com/?x=% comes back as 400 Bad Request.

These two snippets aren’t the only way to handle this. The goal is just to block malformed URLs before they reach your app, however you do it. If you’re running mod_security, for example, a rule that rejects URIs containing invalid percent-encoding will get you the same result. Same idea for any WAF, edge filter, CDN, or load balancer in front of your stack: catch the bad request, return a 400, move on.

If your Xojo app is exposed directly to the internet

If your Web app is talking to the internet without a reverse proxy in front of it, your options are narrower. On Web 2, upgrade to 2026r1.2 if you can. On Web 1, or on Web 2 if upgrading isn’t an option, you’ll need to put Apache, Nginx, or Lifeboat in front of your app, or move to Xojo Cloud, our managed hosting solution.

This is also a good moment to revisit the setup more broadly. Xojo recommends always serving Web apps behind a web server, both for performance and as a defense-in-depth measure against bugs like this one. A reverse proxy would have neutralized this specific issue before it reached the framework, and it’ll do the same for the next class of issue too.

If you use DecodeURLComponent in a non-Web project

The crash isn’t unique to Web. If you’re calling DecodeURLComponent on input you don’t control (anything coming from a user, a file, a network response, a clipboard), the same bug can hit a Desktop, Console, or other project type.

Upgrade to 2026r1.2 if you can; that’s the proper fix.

If you can’t upgrade, you’ll need to sanitize the input yourself before calling DecodeURLComponent. The check is simple in principle: every % in the string must be followed by exactly two hexadecimal characters (0-9, A-F, a-f). If any % doesn’t meet that condition, treat the input as invalid and don’t pass it to DecodeURLComponent. A small helper that validates the string up front and either returns early or substitutes an empty value will keep your app from crashing on the same kind of malformed input that triggers the Web bug.

Acknowledgments

Thanks to the user who reported this through both public and private channels. That’s exactly the kind of disclosure that lets us turn a fix around in under a week. Thanks also to Tim Parnell for the fast Lifeboat update, which gave self-hosted users a drop-in mitigation almost immediately.

If you find a security issue in Xojo, please report it privately. You can email support@xojo.com or file a confidential issue on the issue tracker. Both reach us, and either one lets us get a fix out before the details become public, protecting the rest of the users.

References

• Release notes for 2026r1.2

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

New Controls

Three new controls have been added to the Web framework in this release, aiming to close the difference gap between Web and the other project types.

WebSwitch is a toggle control that mobile developers will already be familiar with. It’s been available on iOS and Android for a while. It’s now available for web projects too, so if you’ve been approximating a toggle switch using a styled checkbox, you can finally retire that workaround.

WebColorPicker brings color selection to web apps in the same way DesktopColorPicker does for desktop. Drop it in from the Library, wire up the event and you have a color picker the Xojo way.

This is how WebColorPicker looks like in your browser:

The third new control adds barcode reading support. Your web app can now read barcodes directly from the user’s camera, from desktop or mobile browsers. This opens up a lot of practical use cases: Inventory systems, ticketing, product lookups, that previously would have pushed you toward a native mobile app.

Again, drop the Barcode control into your project and implement the events:

That’s it! Your web apps can scan a great variety of barcodes now. Including QR, Data Matrix, Aztec, PDF 417 and much more!

Icons on WebButtons

WebButton now has an Icon property. You can assign any WebPicture to it, or use one of the Bootstrap icons that are already bundled with the framework. It’s a small addition, but it makes a noticeable difference when building action-heavy interfaces where a label alone doesn’t communicate enough at a glance.

Add a button into your project:

Configure its Icon property in the Opening event:

Me.Icon = WebPicture.BootstrapIcon("key-fill")

If you don’t specify a color in BootstrapIcon, it will inherit the button caption color in this case. This is the easiest way to support Dark Mode with the new WebButton.Icon property, without doing any special tricks.

Here is how it looks like at runtime:

Dark Mode:

WebLabel: Semantic HTML and Proper Element Types

Two related changes landed for WebLabel in this release. The first is a correctness fix: the control was previously rendered using the HTML <label> element, which is semantically meant to label form inputs, not to display general text. That has been corrected.

The more interesting addition is that you can now choose which HTML element WebLabel renders as. If you want a label to be an <h1> or an <h2>, you can set that directly in the Inspector. This is useful not just for visual styling, but for accessibility tools and search engines that rely on page structure to understand content hierarchy.

Improving both, accessibility and making search engines happier, are some of our goals for 2026. You will continue seeing improvements in this sense.

WebTextArea Gets AddText

WebTextArea now has an AddText method, consistent with how the control works on Desktop and Mobile. If you’re writing code that targets multiple platforms, this kind of parity saves you from having to check which target you’re on, before appending text.

Scale Indicator on WebMapViewer

WebMapViewer now has a HasScaleIndicator property. When enabled, a small visual scale appears on the map showing real-world distance. It makes a difference in apps where users need spatial context. Field work, logistics or anything where “how far is that?” is a question users might actually ask.

Performance and Modernization Under the Hood

A few changes in this release won’t be immediately visible, but they improve things for everyone.

Bootstrap has been updated to v5.3.8 which fixes some issues introduced in v5.3.7 impacting Xojo. The TypeScript compiler has been updated to v5.9.3, and the compilation target has been bumped from ES6 to ES2020. Unused code in the Web Framework has been cleaned up to reduce the compiled bundle size.

Xojo has also removed its own internal usage of Modernizr. The library is still present for now so existing apps that rely on it won’t break, but it’s no longer used by the framework itself and will be removed in a future release.

If you’ve been meaning to audit your web app for performance, this is a good moment to look at SendEventsInBatches and LazyLoadDependencies on WebSession as well. Both now default to True on new projects, so if your existing app has them disabled, it’s worth trying them out. These properties have been around for a while already but were turned off by default.

API Consistency Cleanups

A few methods have been deprecated in favour of names that are consistent with the rest of the framework:

• WebApplication.AutoQuit → AllowAutoQuit
• WebListBox.ReloadData → ReloadFromDataSource
• WebRadioGroup.RemoveAllRows → RemoveAll, and RemoveRowAt → RemoveAt

Your existing code will still compile, but it’s worth updating these when you get a chance.

Wrapping Up

Between new controls, better HTML semantics, and a leaner runtime, 2026r1 is a worthwhile update for anyone building web apps with Xojo. Check out the full release notes for the complete list of changes.

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This is where ngrok comes in: a fantastic tool that creates secure tunnels to your localhost, making your locally running Xojo web app accessible from anywhere in the world. It’s a game-changer for testing, demonstrations, and rapid development.

What is ngrok and Why Xojo Developers Need It?

At its core, ngrok is a command-line tool that creates a secure, public URL for a service running on your local machine. Think of it as a temporary bridge from the internet directly to your computer, bypassing firewalls and NAT configurations.

For Xojo Web developers, this offers a wealth of benefits:

• Real-device Testing: Test your Xojo web app’s responsiveness and functionality on actual mobile phones, tablets, or other computers, even if they’re not on your local Wi-Fi network.
• Instant Demonstrations: Share your work-in-progress with clients, colleagues, or friends without the need of deploying to a remote server. They just need the ngrok-provided URL!
• Webhook Development: Many third-party services (payment gateways, messaging platforms, etc.) use webhooks to notify your application of events. These webhooks require a public URL to send data to. ngrok provides this, making local webhook development a breeze.
• Debugging Public-Facing Issues: Sometimes, an issue only appears when your app is publicly accessible. ngrok allows you to debug such scenarios without a full deployment cycle.

It’s truly a must-have tool in your Xojo Web development toolkit!

Getting Started with ngrok

Before we connect our Xojo app, we need to get ngrok set up.

Step 1: Download ngrok

Head over to the official ngrok website: https://ngrok.com/download.

Download the version appropriate for your operating system (Windows, macOS, Linux).

Step 2: Unzip and Place

Once downloaded, you’ll get a single executable file (e.g., ngrok.exe on Windows, ngrok on macOS/Linux). Unzip it and place it in a convenient location. I recommend creating a dedicated folder for it, or placing it somewhere easily accessible from your terminal or command prompt.

Preparing Your Xojo Web App

Xojo Web applications are self-contained web servers. When you run a Xojo Web app in debug mode or build it for deployment, it listens for incoming connections on a specific port. By default, Xojo Web apps usually listen on port 8080.

Let’s quickly ensure your Xojo Web app is ready:

1. Open your Xojo Web Project: Open any existing Xojo Web project, or create a new one for testing.
2. Run in Debug Mode: Click the “Run” button in the Xojo IDE. Your web app will launch in your default browser, at http://localhost:8080.

Tunneling Your Xojo App with ngrok

Now for the magic! With your Xojo Web app running locally, we’ll open a tunnel to it using ngrok.

Step 1: Open Terminal/Command Prompt

Open your system’s terminal (macOS/Linux) or Command Prompt/PowerShell (Windows).

Step 2: Navigate to ngrok Directory (if needed)

If you didn’t place the ngrok executable in a system PATH location, navigate to the directory where you unzipped ngrok using the cd command. For example:

cd /path/to/your/ngrok/folder

Step 3: Run the ngrok Command

Now, execute the ngrok command to create the tunnel. Since Xojo Web apps typically run on port 8080, the command will be:

ngrok http 8080

• http: Specifies that we’re tunneling an HTTP service.
• 8080: This is the port your Xojo Web app is listening on. If you’ve configured your Xojo app to use a different port (e.g., in the Build Settings), make sure to use that port number instead.

After running the command, ngrok will output information about the tunnel it has created. You’ll see output similar to this:

ngrok                                                                            (Ctrl+C to quit)

Session Status                online
Account                       Account Name (Free)
Version                       3.x.x
Region                        United States (us)
Forwarding                    https://a52b-20-40-100-120.ngrok-free.app -> http://localhost:8080

Connections                   ttl     opn     rt1     rt5     p50     p90
                              0       0       0.00    0.00    0.00    0.00

The most important lines here are the Forwarding lines. These provide you with the public URLs that point to your Xojo web app.

Testing Your Public Xojo App

With the ngrok tunnel active, your Xojo web app is now live to the world!

1. Copy the HTTPS URL: Copy the https:// URL provided by ngrok.
2. Test It:
   • Paste this URL into any web browser, on any device, anywhere with an internet connection.
   • Send the URL to a friend or client to get their feedback.
   • Test it on your mobile phone’s browser using its cellular data connection (not your local Wi-Fi) to simulate a truly external connection.

You’ll see your Xojo web app load as if it were hosted on a remote server!

To stop the ngrok tunnel, press Ctrl+C in the console.

Conclusion

ngrok can be an indispensable tool for any Xojo Web developer. It transforms the challenging task of exposing a local web app into a simple, one-line command. Whether you’re testing on diverse devices, showcasing your progress to clients, or integrating with external webhook services, ngrok streamlines your workflow and lets you focus on what you do best: building amazing applications with Xojo.

Give ngrok a try on your next Xojo Web project, and prepare to be amazed by the convenience it offers!

What if we create a Build Step script to automatically run ngrok when needed? Share your experiences and tips in the Xojo forums!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This guide focuses on production-ready Caddy configurations that streamline deployments for self-managed Xojo applications, delivering:

• Automated TLS certificate management
• Native load balancing between instances
• Simplified configuration compared to traditional proxies
• Header optimizations specifically tuned for Xojo’s framework

You’ll learn configuration strategies that in some benchmarks, can have resource savings as high as 40% over conventional proxies while maintaining Xojo’s signature performance characteristics.

Core Configuration Strategies

Basic Reverse Proxy Setup

yourdomain.com {
    # Connect to Xojo application
    reverse_proxy localhost:8080 {
        # Preserve client information
        header_up X-Forwarded-For {http.request.remote.host}
        header_up Host {http.request.host}
    }
    
    # Automate HTTPS
    tls admin@yourdomain.com
}

Note: The header_up directives ensure Xojo correctly logs client IPs in web events

Load Balancing Across Instances

app.yourdomain.com {
    reverse_proxy localhost:8080 localhost:8081 localhost:8082 {
        load_balancer {
            policy round_robin
            health_interval 10s
            health_uri /health
        }
        # Timeouts for heavy processing
        lb_try_duration 30s
    }
}

Security Hardening Measures

yourdomain.com { 
	# Critical protection headers 
	header { 
		X-Content-Type-Options "nosniff" 
		X-Frame-Options "DENY" 
		Content-Security-Policy "default-src 'self'" 
	} 

	# Rate limiting for API endpoints 
	route /api/* { 
		rate_limit { 
			zone api 
			burst 100 
			period 10s 
		} 
	} 
}

Production-Ready Deployment Scripts

Linux Systemd Service
/etc/systemd/system/xojo-caddy.service:

[Unit]
Description=Xojo Caddy Reverse Proxy
After=network.target

[Service]
Type=simple
User=caddy
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

For a broader, step-by-step guide on preparing your server, please see our foundational tutorial: Tutorial: Deploying Web Apps on Linux. The systemd service above integrates perfectly into that workflow.

Windows Deployment Package
Xojo-Caddy.bat:

@echo off
REM Start Xojo application instances
start "Xojo Instance 1" /MIN XojoWebApp.exe --port=8080
start "Xojo Instance 2" /MIN XojoWebApp.exe --port=8081

REM Launch Caddy reverse proxy
start "Caddy Proxy" /MIN caddy.exe run --config C:\caddy\Caddyfile

Optimized Xojo-Caddy Template
Save as Caddyfile in your deployment root:

# Production-Grade Xojo Proxy Template
yourdomain.com, www.yourdomain.com {
    # Automated HTTPS
    tls contact@yourdomain.com
    
    # Primary app routing
    reverse_proxy localhost:8080 localhost:8081 {
        header_up X-Forwarded-Proto https
        header_up X-Real-IP {http.request.remote}
    }
    
    # Static content handling
    handle /static/* {
        root * /var/www/static
        file_server
    }
    
    # Security headers
    header {
        Strict-Transport-Security "max-age=31536000"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Conclusion

Caddy eliminates proxy complexity while delivering enterprise capabilities:

1. Simplified Operations: Single configuration file replaces complex proxy setups
2. Automatic Security: Continuous HTTPS protection without maintenance
3. Effortless Scaling: Built-in load balancing grows with your user base
4. Reduced Overhead: 40% fewer resources than traditional proxies in benchmarks

Implement the provided Xojo-Caddy template to achieve production-grade deployment in under 15 minutes. Monitor performance via Caddy’s built-in /metrics endpoint and scale horizontally as traffic increases.

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube