Hey everyone! PCMR has teamed up with MSI and BuildCores to see how you’d configure a build around the awesome MSI MEG MAESTRO 900R, and it's a WORLDWIDE GIVEAWAY!

Design your setup in BuildCores, share the thinking behind your build, and you could win a MEG MAESTRO 900R case and MEG CORELIQUID E15 360 liquid cooler!

HOW TO ENTER

• Head to the BuildCores website (or use the app) and click the Start Building button.
• Create a PC configuration on BuildCores featuring the MSI MEG MAESTRO 900R case, an MSI motherboard, and an MSI liquid cooler. The other parts are 100% your choice!
• Post a comment in this thread with your build configuration in text, the BuildCores share link, a screenshot of your configuration, and a short explanation of why you chose that layout and those components.

Need a hand? See an example entry: [Example Image]

To share your build: Use the Share button in BuildCores: [Example Image]

BuildCores is currently in Beta, so you may find some bugs here or there. If you do, be sure to give them feedback on their sub r/buildcores.

THE PRIZES

• 2 winners, with each winner receiving an MSI MEG MAESTRO 900R PC case and an MSI MEG CORELIQUID E15 360 liquid cooler.

You can enter until Oct 31, 2026! 

Good luck, and may your framerates be high, and your temperatures low!

------------------------

About the case and MSI's MEG series:

If you're not familiar with MSI’s MEG (which stands for MSI Enthusiast Gaming) lineup, it’s essentially their flagship series, aimed at enthusiast builds and overall enjoyers of higher end options.

For the MEG MAESTRO 900R being given away here, here’s what MSI is highlighting: a centered internal layout, three-sided panoramic glass, and a detachable motherboard tray that can rotate into four different orientations. That gives builders quite a few options for how they want to assemble and display their system.

There are also some more premium finishing touches, including aluminum panels and diamond-cut detailing.

The four-way motherboard layout is probably the most interesting part from a builder’s perspective!

If you want to see MSI’s full breakdown of the MEG series, you can check it out here: "Excellence, Refined".

------------------------

The winner will be contacted by Reddit direct message (please make sure your DMs are open) in the 7 days after the event ends, and announced on this thread as well.

One entry per Reddit account; only your first eligible comment will count.

The prize winners will be selected randomly from all eligible entries on Nov. 7, 2026.

Participants must be 18+ and reside in eligible territories.

Winners must respond within 7 days, or a new winner may be selected.

Full terms and conditions please check here.

There's never a dull moment.

What's happening?

Over the past two days, there's been a whole bunch of security issues found in lots of very popular software. While for the most part our userbase is gaming focused, for which this won't have a huge impact and might already be effectively mitigated, I know for an absolute fact there's a bunch of developers and homelabbers in our audience that will need to take action to protect their stuff. (frankly idk why you'd be finding this out via PCMR and not somewhere else given the timing of this post and the scale of the issues, but who knows?)

Issue 1: Two extremely serious PHP remote code execution vulnerabilities

Yesterday, the PHP Foundation announced that there were two critical remote code execution (RCE) bugs present in all versions of PHP dating back to PHP 5. A remote code execution bug means that someone can upload their own code to a server and run it, which in this case can lead to the entire application or server falling under control of the attacker. Realistically, this could mean your application can be used to serve spam, siphon site visitor information and send it somewhere else, put your computer into a botnet, mine cryptocurrency for someone else, infect your server with ransomware, or worse.

Basically all versions of PHP past version 5 (first released in 2004) are vulnerable, with specific PHP runtimes like mod_php being called out in the security advisories as especially at risk because the vulnerabilities run before any application code. There are mitigations available, but these don't fix the underlying issues and are band-aids on the problem instead.

Since this affects the actual PHP runtime, this also affects all manners of software built on top of PHP. A very non-exhaustive list of common examples in the self-hosted application space include:

• CMS systems like WordPress, Drupal, and Joomla
• Self hosted cloud systems like Nextcloud and ownCloud
• Wiki software like MediaWiki, DokuWiki, and Bookstack

Please comment other popular self hosted apps running on PHP; I know I'm missing quite a few.

As /u/joblessandsuicidal noted in the comments, this also will affect network devices like internet routers that run PHP for their admin interfaces. That's... not great, to put it lightly, as those devices tend not to auto update and a lot of older devices simply don't have manufacturer support anymore, meaning they'll never be updated.

Full technical details for the vulnerabilities are available here:

• CVE-2026-109618 - RCE via OOM corruption
• CVE-2026-109619 - RCE via stale global state

Issue 2: Intermediate TLS certificate private keys discovered

Also yesterday, a critical weakness was discovered in some of the certificates used for SSL/TLS (a fundamental backbone of digital security; literally the "S" in "HTTPS" and so many other protocols). When you try going to any website using HTTPS (practically all of them nowadays), there's a bit of complex math that goes on behind the scenes where your computer verifies that the server that you're communicating with is who it says it is. The specifics are a bit complicated, but to oversimplify there's several Extremely Trusted groups that your computer implicitly trusts (aka root certificate authorities, or root CAs), and then those Extremely Trusted groups trust other Not Quite As Trusted But Still Very Trusted groups (intermediate CAs), and then however many more steps down the chain you've got regular servers and websites where their identity is vouched for by a more trusted authority. If a trusted certificate authority has validated that your server belongs to your domain name, it lets you through no problem. All operating systems have a set of trusted certificates pre-installed by default, as do all sorts of non-computer devices that talk over the internet.

Yesterday, eight intermediate certificates from a smaller intermediate CA called eMudhra had their private keys leaked. These private keys are basically a really, really long number (2³⁸⁴ possible values, which if you turn that into a decimal is a number with 116 digits in it) that then gets churned through a bunch of complicated math to produce the public keys that then get distributed to computers. The private keys leaking is already Very Bad™ on its own, since this means that if your computer still trusts those certificates anyone can pretend to be any website on the internet (which can lead to convincing phishing attacks, man-in-the-middle attacks, secure traffic decryption, and so on), but the details are a bit stranger. All of the private keys were insanely weak, with the full keys having only 8 bits of randomness at the very most (instead of 384 bits like they should). One of the private keys was 4. Not four digits, not four bits of entropy, but literally just the number 4. I have no words. That's just about as funny as it is terrifying, and it's pretty damn funny.

(Moderator note: if we catch anyone being racist in the comments towards the CA in question or anyone from their country of origin, you're getting banned. Consider this your warning.)

Issue 3: Plex vulnerability allows for remote code execution

Similarly to the PHP discoveries, users of the media streaming server software Plex need to update immediately. For the unfamiliar, Plex is akin to "self hosted Netflix" and lets you stream videos you have stored on your own hard drive to your TV, phone, or other devices. A common setup is to have your Plex server exposed publicly to the internet so you can watch your stuff outside of your home network, and that's where this issue takes hold.

Assuming you're running Plex on the default port of 32400 and have it publicly exposed to the internet, attackers can string together four different vulnerabilities (tracked as CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656) to gain remote code execution capabilities. It's already being exploited in the wild and has been used thus far to deploy crypto miners on vulnerable servers and residential proxies, which cybercriminals can use to route attack traffic towards various businesses through "clean" IP addresses that don't have as bad a security reputation as those from datacenters and typical VPN providers.

Am I affected?

If you're an average user who doesn't self-host any server software, most likely not. For Issue 1, this affects the sites and services themselves. For Issue 2, basically all major browsers actively track certificate revocations, and those got updated within hours of the compromise dropping. You can check if your browser got updated here; you want all greens to know that your browser is updated. You can also click each individual certificate to how the browser responds; if you get a certificate error, then you're good. For Issue 3, if you don't run Plex Media Server, then you're not affected.

One caveat to the above: if your internet router runs PHP for its admin dashboard, it will be vulnerable. Make sure to update your router as soon as a new update is available, if it's still getting support. This might be a case where you need to replace the hardware if it's out of support.

To break it down a bit further:

• PHP vulnerabilities

  • If you're a developer who works on PHP stuff, well, godspeed. You'll absolutely need to update your stuff.
  • If you run any self-hosted software that runs on PHP, that will absolutely need to be updated the moment a patch is available. If you're running the applications on bare metal or in a VM, you might need to update the runtime manually. If you're using a Docker container or similar, wait til a container update is available, as that'll likely update the runtime. Ensure you're not pinning a vulnerable PHP version if the app is served via a sidecar container with the PHP runtime.

• TLS certificates

  • Your browser should have auto updated already to revoke the bad certs. You can check here
  • iOS and Android should also have auto updated their own revocation lists.
  • Your operating system will need to have its own CA store updated. Windows handles updating its CA store behind the scenes, and macOS does so too (albeit not completely). On Linux, you'll need to update the cert store manually. A list of updated packages can be found here
  • If you self-host anything, your Docker containers will need to be updated with a fresh copy of the CA store. Should be a similar process to Linux
  • If you develop any server software, also check your application runtimes to ensure they have fresh bundled certificate store data. A list of patched runtimes or request libraries can be found here

• Plex

  • If you're running Plex Media Server 1.43.3.10860 or earlier, you're vulnerable.
  • If you're not running Plex, you're not vulnerable.

How do I fix this?

Update your stuff.

PHP issues

General users

You don't need to do anything in particular in most cases.

If you have an internet router, network switch, or similar device that uses PHP for its admin interface, keep an eye on the manufacturer for firmware updates, then install that as soon as you can. Unfortunately, not all routers and such actually get manufacturer support like this, meaning that there's a possibility it might never get updated. In that case, you'll need to get a new router that's on an updated software version.

If you run router firmware like pfSense or opnSense (both running PHP), patches should be dropping Soon™ to address the issues.

Developers

The following runtime versions are now available and should be tested as ASAP as possible:

• 8.5.12
• 8.4.27
• 8.3.36
• 8.2.35

Versions 8.1 and older aren't being actively supported by the PHP Foundation anymore, though minimal source backports exist for PHP 7.4, 8.0, and 8.1 that can be used to compile a new version. If you have an LTS vendor, check with them to see if they have compiled backports for other versions. If you're on versions of PHP older than 7.4, I guess now's as good a time as any to fast-track an update to PHP 8.5 or to get an LTS vendor.

If you absolutely cannot update immediately, the PHP Foundation published the following mitigations for the issues. These are not fixes and still leave you vulnerable, but should hopefully buy you some time.

RCE via OOM corruption (CVE-2026-109618):

• Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
• Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
• Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

RCE via stale global state (CVE-2026-109619):

• Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
• Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
• Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.

Self hosters

Update any PHP-powered applications as soon as the updates come out. If you set up your own runtime for specific applications, like Wordpress, update that runtime ASAP.

TLS issues

General users

Update your browsers and update your OS so they pick up on the revoked certificates.

• Windows should handle the updates automatically.
• macOS updated its own revocation file, but some built-in system tools don't check the revocation list. If you don't want to wait for Apple to fix that properly, there's a workaround here.
• On Linux, update the ca-certificates package (or equivalent for your distro). Specific versions of ca-certificates that patch it can be found here, though they'll probably filter through your package manager on next update.

Developers

Update your OS, any containers you might build (both with an updated OS image and with an updated runtime image if applicable), and any runtimes/request libraries that you might use. A list of updated runtimes can be found here.

Self hosters

Update any applications or Docker containers as they come out.

Plex issue

Update your install of Plex Media Server to Plex 1.43.3.10861 or later.