2026-11 Security Patch

Please apply this now. A flaw in the osTicket Awesome settings page lets someone with no login change your settings and, on servers that can save uploaded logos or custom background images, upload a file and run it. Attackers are actively trying it.

The patch is free for everyone, whether your license is current or lapsed. You don’t need to log in or renew.

Download the patch

SHA-256: 1e5838df5c5757a2568bfef47cfd0901d512a27f692c6cb2628d8ec932f19dd9

Questions or discussion: join the forum thread for this notice.

Who needs this

Every installation from 1.12-Awesome-102 through 1.18.4-Awesome-102.

The same ZIP works on all of these versions. It doesn’t change your version number or your settings.

This patch fixes this one flaw, not your whole installation. Older osTicket versions have other published security problems. For example, osTicket before 1.18.3 and 1.17.7 is affected by CVE-2026-22200, which lets anonymous visitors read files on the server. Please plan an upgrade to the current release.

Releases before 1.12-Awesome-102 don’t have this upload flaw, so this patch isn’t for them. They do let visitors change the title text shown on your pages, which can be used to attack people who view them, so please upgrade those too.

Apply the patch

  1. Back up your osTicket folder and database.
  2. Download the ZIP above and extract it.
  3. Copy the osta folder over the osta folder in your osTicket folder, and let it replace existing files. Four files are replaced or added, all inside osta/.
  4. Check that osta/uploads/.htaccess arrived. Some programs hide files that start with a dot.
  5. Restart PHP or your web server. PHP can keep running the old file from its cache until you do, so the patch may not take effect without this step.
  6. Log in as an administrator, open your theme settings page (scp/theme.php), and click Save Changes once. This cleans any settings an attacker changed.

On nginx, on Apache as installed by default on Ubuntu or Debian, or on any Apache that doesn’t read .htaccess files, you must also add the server rules. The included .htaccess file has no effect there. Windows IIS users get a web.config file in the same folder.

Newly uploaded logos and backdrops now get a generated filename, and animated GIFs become still images. Your existing images aren’t changed.

If logos stop loading and the server shows a 500 error for that folder, your Apache allows only some .htaccess directives. Replace the contents of osta/uploads/.htaccess with the shared hosting rules.

Check for a break-in

The patch closes the hole. It doesn’t remove anything an attacker already added, so please check your files, your logs and your database.

Files

  • osta/uploads/ should hold only images, index.html, .htaccess and web.config. Anything else means your server was reached, especially a file ending in .php, .phtml or .phar.
  • Look beyond that folder. Once an attacker can run code, they can put files anywhere your web server can write. One customer found inject.php in the top level of their server. Filenames vary. We’ve also seen attackers ask for fetems42.php and theme.ver.php.
  • Compare your files with a clean copy. Any PHP file that isn’t in the ZIP for your version needs an explanation.
  • List recently changed PHP files. On Linux, run this in your osTicket folder, using a date before you suspect anything happened. It uses the change time, which is much harder to fake than the modified date:
find . -type f '(' -name '*.php*' -o -name '.htaccess' ')' -newerct '2026-09-01'
grep -rl '<?php' osta/uploads/

Logs

Search your web server access logs for choose-theme.php and osta/uploads/.

  • Attack pattern: a POST to /osta/css/themes/choose-theme.php, then within seconds a GET for a .php file in /osta/uploads/. A 200 response to that GET means the file ran. A 404 means that attempt failed.
  • One address we know: the attempts on our own server and on a customer’s server came from 200.9.154.156. Search your logs for it. Other attackers will use other addresses, so a clean result here proves nothing on its own.
  • Normal use is a POST with scp/theme.php as the referrer, from an address your admins use. A referrer can be faked, so check the address too.
  • In your PHP error log, the line update_config() called with incomplete POST data from an unknown address is a failed attempt on 1.18.3-Awesome-104 or later. Failed attempts mean your site is being probed, and a later one could succeed.
  • Also in your PHP error log, any warning or error whose path contains osta/uploads/ and eval()'d code means uploaded PHP ran on your server, even if the file has since been deleted.

Database and settings

  • Agents: look for administrators you don’t recognize.
  • API keys and plugins: look for any you didn’t add.
  • Theme settings: check the title, subtitle, mobile link, cookie message and custom CSS.

A clean result isn’t proof

An attacker who ran code can delete their own files, change modified dates, and sometimes edit logs. Old logs may also have rotated away. If your site was exposed and you can’t account for what happened, assume the worst.

If you find anything

Treat the whole server as compromised. Copy your logs somewhere safe first. Attackers usually leave more than one way back in, so deleting a single file isn’t enough. Restore from a backup made before the break-in, or rebuild the server, and then apply this patch.

Your database password was readable, so change it, along with your admin and email passwords and any keys stored on the server. Your tickets and customer details may have been read too. Check whether you have to notify anyone. Please contact us before changing SECRET_SALT, because that can lock out your staff and stored email accounts.

If you can’t patch today

You can block the flaw at your web server until you’re ready. See the server rules for Apache, nginx and IIS.

Questions

Does updating PHP fix this? No. This flaw is in osTicket Awesome’s own code and is separate from the recent PHP vulnerabilities. Please keep PHP patched as well.

How do I know which version I’m running? Open the osta/version file in your osTicket folder.

Was any data held by osawesome.com affected? Our store doesn’t run the affected code. Test sites on the same server did. We’ve locked them down and found no sign they were exploited, but our logs don’t reach back far enough to rule it out completely.

Is a full release coming? Yes. 1.18.4-Awesome-103 includes this fix and will follow shortly.

Something else? Ask in the forum thread for this notice and we’ll answer there.

Get help

If you need a hand or have found signs of a break-in, please contact us.

Timeline and updates

All times are Pacific time.

  • May 2019: The flaw is introduced in 1.12-Awesome-102.
  • 2026-09-30: Someone probes the flaw on our demo site, unsuccessfully. We found this later, while reviewing our logs.
  • 2026-11-05: An attempt against our own support server fails.
  • 2026-11-06, 8:50 am: A customer reports the flaw. We confirm it the same morning.
  • 2026-11-06: We lock down our own servers, test a patch on all 69 affected releases, and publish it with this notice.
  • 2026-11-06, 5:25 pm: Notice emailed to customers with active subscriptions. Notices to past customers follow.