FireFox Browser update causing HTML to display as TEXT

[Bruce Cloutier]

Just an FYI. If you use FireFox to access a web-based GUI on devices (like the JNIOR Series 4) you may get raw HTML displayed. There is some obscure vulnerability (CVE-2025-11712) that is prompting browsers to now block sites that do not have a Content-Type header (previously not required with PHP) and that utilize JavaScript.

One solution is to NOT use FireFox. I notice that it gets a crazy amount of hate on Reddit. Chrome still works.

I had to modify our WebUI to define the header. This isn't an operating system or web server issue. Pages being generated by PHP (and that include JavaScript) will need to deliberately include the header statement. That was not required in the past.

So I have added it to our WebUI index.php file. You can update your /flash/www/config.zip file on all of your JNIORs. Yeah, I don't like it either. You can update using the Support Tool although I am not sure if all of the update projects will themselves be updated immediately. It might be best to check with Support.

One neat thing that the JNIOR does is to serve an entire website out of a ZIP file. You don't need to extract the content. In fact the name of the ZIP serves as a virtual folder. So if you create a custom webpage by adding your own index.html file in /flash/www, you can still get to the WebUI using the URL [IP-Address]/config. So to update the WebUI just replace that file.

It would be good if you were to all run the latest OS in your JNIORs. But I don't trust anyone else's updates (especially MS) so, I can't expect that you would trust mine.

[Frank Cox]

A work-around that might be more work than the fix, but could be worth it if you're using some kind of legacy equipment that you can't update, would be use greasemonkey to inject that header into the relevant webpages.

[Ed Gordon]

Google AI reports this:

AI Overview

Modern web browsers are increasingly enforcing stricter security policies, and the absence of a Content-Type header, especially when serving JavaScript, is now considered a significant security risk. This change in browser behavior is driven by the need to mitigate vulnerabilities like Cross-Site Scripting (XSS).

The Rationale:

• MIME Sniffing Prevention:
  Without a Content-Type header, browsers might perform "MIME sniffing" or "content sniffing" to guess the type of content being served. This can lead to security vulnerabilities where a seemingly harmless file (e.g., a text file) could be misinterpreted as executable code (like JavaScript) and executed within the user's browser, potentially leading to XSS attacks.
• Clear Content Interpretation:
  Explicitly setting the Content-Type header ensures that the browser correctly interprets the content. For example, if a file contains JavaScript, the Content-Type should be set to application/javascript or text/javascript. This eliminates ambiguity and prevents malicious content from being executed unintentionally.
• Enhanced Security Standards:
  The web security landscape is constantly evolving, with browsers implementing more robust security measures to protect users. Requiring Content-Type headers for scripts aligns with these enhanced security standards and helps prevent a range of client-side attacks.

Impact on PHP and JavaScript:

Previously, some PHP configurations might have allowed serving files without explicit Content-Type headers, and browsers might have been more lenient in interpreting them. However, with the increased focus on security, modern browsers are now stricter. If a PHP script serves JavaScript content without a Content-Type header, browsers are likely to block its execution to prevent potential XSS vulnerabilities.

Resolution:

To ensure compatibility with modern browsers and maintain web security, it is crucial to explicitly set the Content-Type header for all responses, especially those containing JavaScript. In PHP, this can be done using the header() function:

Code

<?php header('Content-Type: application/javascript');
// Your JavaScript code here echo 'console.log("Hello from JavaScript!");'; ?>

This seems to indicate any/all browsers might have this problem.

[Frank Cox]

https://nvd.nist.gov/vuln/detail/CVE-2025-11712

This vulnerability affects Firefox < 144, Firefox ESR < 140.4, Thunderbird < 144, and Thunderbird < 140.4.

I have no idea why it doesn't affect other web browsers but the advisory lists only Firefox and Thunderbird, as you see.

[Bruce Cloutier]

I am a bit confused as to what the vulnerability really is? I suspect the approach of requiring the Content-Type might have been a quick decision by someone without a detailed understanding of all use cases and who/what it might impact. This likely falls in line with addressing the symptom and not fixing the problem. Or, maybe, more along the lines of a deal where we have to take our shoes off to get on a plane for a couple of decades. In any case, it makes sense that there should be a Content-Type defined. Its just that 10 years ago PHP documentation made no mention. I don't think it does yet.

Well, with PHP you can generate all kinds of content for downloading and AJAX kinds of interfaces. In those situations we do force the Content-Type header entry. It just didn't seem to be required for rendering pages.

Anyway, in our case it is easily remedied but it will plague techs for years. You know that in my case it drives me nuts that third parties can make decisions that impact the quality of your product and the customer's experience at any point and at any time.

[Frank Cox]

I am a bit confused as to what the vulnerability really is?

https://cwe.mitre.org/data/definitions/116.html

Improper encoding or escaping can allow attackers to change the commands that are sent to another component, inserting malicious commands instead.
Most products follow a certain protocol that uses structured messages for communication between components, such as queries or commands. These structured messages can contain raw data interspersed with metadata or control information. For example, "GET /index.html HTTP/1.1" is a structured message containing a command ("GET") with a single argument ("/index.html") and metadata about which protocol version is being used ("HTTP/1.1").
If an application uses attacker-supplied inputs to construct a structured message without properly encoding or escaping, then the attacker could insert special characters that will cause the data to be interpreted as control information or metadata. Consequently, the component that receives the output will perform the wrong operations, or otherwise interpret the data incorrectly.

[Harold Hallikainen]

I just looked at the headers sent from one of my web sites (like https://w6iwi.org ), and the content-type header appears to be inserted by Apache based on the filename extension. An index.php shows " Content-Type: text/html; charset=UTF-8". I'll check stuff like the USL IRC-28C where the web server is Microchip library code in C.

From what I'm reading, the concern is stuff like SQL injection as described at https://xkcd.com/327/ .

[Jim Cassedy]

<edited> One solution is to NOT use FireFox.

I've used FireFox for close to 20 years, but I've been slowly migrating to Chrome.
I don't fully know what FireFox's main vulnerabilities are, but in the past year,
several websites, such as the ones for my utility company, my bank, my health
care provider, and several work related services no longer support Firefox, and
you can't even connect to them any more with the F-F browser. Aside from that,
F-F is constantly updating- occasionally more than once a week. In fact, I just
got another 'update' notification this morning.

[Ed Gordon]

I've used FireFox for close to 20 years, but I've been slowly migrating to Chrome.
I don't fully know what FireFox's main vulnerabilities are, but in the past year,
several websites, such as the ones for my utility company, my bank, my health
care provider, and several work related services no longer support Firefox, and
you can't even connect to them any more with the F-F browser. Aside from that,
F-F is constantly updating- occasionally more than once a week. In fact, I just
got another 'update' notification this morning.

I have used Firefox for years, but I am moving to Brave. I got tired of the constant updates from Firefox. They like to brag about "new features" but ignore reported bugs that never get fixed. I avoid Chrome because it is literally a data vacuum.

From AI:

Yes, Google Chrome is known for collecting a significant amount of user data, including browsing history, location, and financial details, making it one of the most data-hungry browsers available. This extensive data collection is primarily used for targeted advertising and improving services

Data Collection by Chrome

Overview of Data Collection

Google Chrome is known for its extensive data collection practices. It collects a wide range of user data, including:

• Contact Information
• Financial Details (payment methods, card numbers)
• Browsing History
• Search History
• Location Data
• User Identifiers
• Diagnostics Data

Comparison with Other Browsers

Google Chrome	20 different types	Collects detailed financial information
Bing	12 different types	Less invasive than Chrome
Firefox	Moderate data collection	Balances privacy and functionality
Brave	Basic identifiers	Focuses on user privacy
TOR	No data collected	Maximum privacy protection

Implications of Data Collection

Chrome's integration with various Google services means that users often share more data than they realize. This extensive data collection is primarily used for targeted advertising and improving services. While users can adjust privacy settings, the default state tends to favor data collection.
In summary, Chrome is indeed a significant collector of user data, often referred to as a "data vacuum" due to its extensive tracking capabilities.

[Frank Cox]

In defence of Firefox, if you use the ESR version it doesn't update very often at all, and Firefox works a lot more effectively with things like ad blockers, javascript managers, cookie managers and the like than Chrome does.

There are a few websites that can't be made to work with Firefox, but not many.

[Bruce Cloutier]

I still use FireFox. I don't think any of them are immune. They all have vulnerabilities. There is a kind of decay occurring.

But if you want to use the WebUI to manage your JNIOR and you haven't updated that unit, you will need to use a different browser.

What I don't understand about the vulnerabilities is why they exist in the first place. It just seems that the Content-Type being missing isn't at the heart of the issue. Does anybody understand that blurb Frank quoted? I mean, other than sounding like it is easy to screw things up?

I think a concern is that, in the name of Security, they keep cranking up the key sizes, deprecating algorithms, and modifying how things work without concern for hard-coded embedded devices.

[Frank Cox]

Here is a simplified example based on my current understanding of how this works.

The attacker creates a malicious HTML file containing a specially crafted filepath to a file on your computer and a command to do something with it. Lets delete it.

<img src="http://example.com/delete.php?file=/path/to/sensitive/file.txt" />

Firefox (or whatever) receives the HTML file and extracts the URL from the `src` attribute of the `img` tag.

Firefox will then construct a request to the server for that script. The `delete.php` script is retrieved and deletes the file on your computer instead of retrieving the requested image.

This is obviously a really contrived example and anything that really worked would have a far more complex structure.

But as far as I can tell, this is the general idea of the attack.

I've heard of this sort of thing on the server side before where a scripts doesn't properly encode user input of some kind, and Firefox doesn't allow access to random files on your computer by default. But there's almost certainly other mischief that wouldn't require that kind of access.