Desktop (endpoint) Log4J Vulnerability ?

  • SpinRite v6.1 Release #3
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


New member
Jul 17, 2022
My fellow students have been debating whether Log4J/Log4Shell can affect a Windows 10/11 PC Endpoint.
One brought forth a scan from a popular vulnerability penetration tool which identified several "weaknesses" on a plain vanilla Window 10 21H2 machine from a few months ago.
It identified a PC as showing several points of concern. (He actually had re-configured the Sacnner's Subnet and looked at one with PCs, not servers on it, in student's curiosity.)

All of my reading indicates that the weak code which makes Log4J an issue lives in a limited subset of Apache Server versions, which was very popular.
The only thing unusual that he had observed on this PC was that IIS was enabled, which was unexpected.
[ Turn Windows feature on or off --> Internet Information Services == > World Wide Web Services (on) + Web Management Tools (on) + FTP Server (off) ]
Most users in this environment did not have the rights to add software or change features, such as IIS.

Can anyone suggest why a desktop PC could be considered vulnerable to Log4J ?
Can anyone suggest why a desktop PC could be considered vulnerable to Log4J ?
This is a complicated topic, and if you're not a Java developer a lot of it might seem over your head and esoteric. It's hard to even talk about it without assuming a certain frame of reference in common, but I will try and give some background to help.

First, what is a logging system, and thus what is Log4J, and why does a developer add one? When you're developing a program, there are many levels of output that you might like to see during development, but you might not want to bother your end users with when the program is finally delivered. A logging system allows the developer to classify a debugging message with levels, such as ERROR, WARNING, INFO, DEBUG. The system itself is also configurable as to which level of messages are output. Additionally, the logger can be configured as to the style and formatting of the messages as well as where they are produced or saved. It can be configured to output to the console or to files (frequently rotated so only so many collect and thus only so much disk space is used for logging.)

The theory of the design is that messages that are not enabled have a minimal impact on the speed of the program that is thus not outputting them (when they're configured off.) This encourages a developer to add these messages when needed, but not have to remove them when development proceeds further. (The developer can leave them in place but configured off, in case s/he needs to come back to that code for further debugging later.)

One hallmark of Log4J is that it can usually be very easily configured with a single system wide configuration file (often in XML but these days other choices exist.) This means that it can be part of almost any piece of code that ever needed debugging, but configured to do nothing. If it's not doing anything in the overall system it's part of then it poses no risk to exploitation by Log4J vulnerabilities. (It should still probably be updated, just in case, and to prevent false alarms by detection systems looking for old potentially vulnerable code.)

As for your original question: it would depend entirely on the software running on the device. Log4J is a sub-component of other software and does not normally have an incoming connection from the network. It would depend on what program was using it. In order for the exploit to occur, and attacker needs to supply input to a program that the program itself will then subsequently supply to an enabled Log4J outputter.

Presumably the scanner can recognize the blob of code that is Log4J (a binary set of Java class files) but not recognize what it is being used to do. When building software in Java, it is very common to use a hierarchical build system that knows about dependencies of sub-components. A logging system like Log4J is very frequently a dependency of other software which gets included if you're building a program and want to make use of re-use of existing code rather than writing all of it on your own. If when present, it might not be configured to be enabled, or if enabled, there might not be a way for the attacker to pass input through it.

As an example, let's pretend you want printed reports out of your Java program, so you use a PDF generation tool that is freely available. The developer of that PDF generation tool may have built it to include Log4J to help with that developers testing. The PDF sub-component will not ship with a Log4J configuration file, so no logging will be done by default when it is included with your code. If you, as the developer of the tool that uses the PDF sub-component, configures logging as well, then you may or may not have the information you need to enable the logging in the PDF sub-component. In any case, the code will be present (because it is a dependency and will not build without it) but if it's not used by the higher level, code, it's not posing a risk. If it is used by higher level code, but that code doesn't output any user input, there is still probably no avenue for an attack. It needs to be the case that the program using Log4J is also somehow allowing user controlled inputs to be passed through to Log4J for output before there is an actual path of attack.
Last edited:
To add to what @PHolder mentioned in his post, to make it clear, the Log4j vulnerability has no relation with the Apache HTTP Server (aka Apache, httpd), nginx, http.sys, Internet Information Services (aka IIS or w3svc), or any other web server. It's an application (sub-)component vulnerability; web servers are a gateway for exposing applications, but it is not the only pathway.