Source: Jan Miks via Alamy Stock Photo

More than eight years after it first came to light, an unauthenticated Java deserialization vulnerability lurking in the Google Web Toolkit open source application framework remains unpatched, and could require fundamental framework fixes to vulnerable applications.

GWT is an open source set of tools that allows Web developers to create and maintain JavaScript front-end applications in Java. According to technology tracking platform Enlyft, there are around 2,000 companies using GWT, the majority of which are small with one to 10 employees and between $1 million and $10 in annual revenue.

In new research, Bishop Fox managing principal Ben Lincoln expressed disbelief that the GWT vulnerability, which allows remote code execution, hasn't been fixed in all these years, adding that the Java deserialization bug is similar to the Spring4Shell vulnerability discovered in 2022.

"If no patch had been issued, then at least the vulnerable framework features (could) have been marked as deprecated, and the framework documentation (could) provide suggestions for replacing vulnerable code with updated alternatives," Lincoln wrote. "At a bare minimum, the framework developers (could) undoubtedly have updated the 'getting started' tutorials and other documentation to indicate the inherent danger of using the vulnerable features instead of highlighting the functionality."

The code's maintainers have taken none of those steps since the GWT flaw was first openly discussed in 2015, Lincoln said, who in his posting detailed exactly how a vulnerable GWT application could be exploited in the real world.

Vulnerable Application Mitigation

Mitigation for exposed Web applications is going to be a heavy lift, Lincoln warns.

The vulnerability is at such a fundamental level "that securing vulnerable Web applications written using this framework would likely require architectural changes to those applications or the framework itself," he explained in his research.

To start, Lincoln tells Dark Reading that administrators running vulnerable applications need to plan for the worst-case scenario and work from there.

"[They should ask] what would we do if our business had to block access to this application starting immediately, and not restore access until a remediation was in place?" Lincoln says.

More broadly, to avoid operating with these types of known, unpatched flaws, he recommends watching how responsive third-party component operators are to patching.

"When they lead to a 'not our problem' type of result, as opposed to a patch, assess whether your organization agrees with that position or if it merits replacing the component, creating a customized version with a remediation, etc.," Lincoln recommends. "If it's deemed low-risk, track it internally as a vulnerability to be reviewed at least annually to see if the organization still reaches the same conclusion."

He adds, "For in-house developed applications, periodically review the list of third-party components they're based on, and consider migrating off of any where popularity or developer activity seems to be on the wane, even if they're not formally abandoned or unsupported."