I haven't seen a real-world WebSockets vuln in ages. Here's a decent, but not very exciting, example. (An exciting vuln would be abusing the custom messages the app was using WebSockets for.) It boils down to a lack of origin verification on the endpoint.
Here's a brief resource from Port Swigger about WebSockets security and some documentation from Zed Attack Proxy on how to use the tool to test WebSockets traffic.
The other vuln is a data leak related to an "expandAtFile" capability in the third-party args4j library that parses command-line options. Args4j has special handling for the "@" symbol, "is used to reference another file that contains command line options separated by line breaks."
Jenkins fixed the flaw by disabling that "expandAtFile" feature.
So, who needs that feature in the first place? Should it have been disabled by default by the library? Should Jenkins have better isolated the process to prevent reading from the filesystem, whether it knew about that args4j feature or not?