Years-Old, Unpatched GWT Vuln Leaves Apps Open to Server-Side RCE

Although the unauthenticated Java deserialization flaw has been known since 2015, GWT apps remain vulnerable to malicious server-side code execution, new research says.

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, hasnt 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 codes 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.
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 its 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 theyre based on, and consider migrating off of any where popularity or developer activity seems to be on the wane, even if theyre not formally abandoned or unsupported.

Last News
▸ Nigerian scammers now turning into mediocre malware pushers. ◂ Discovered: 23/12/2024 Category: security	▸ Beware EMV may not fully protect against skilled thieves. ◂ Discovered: 23/12/2024 Category: security	▸ Hack Your Hotel Room ◂ Discovered: 23/12/2024 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Years-Old, Unpatched GWT Vuln Leaves Apps Open to Server-Side RCE