Researchers developed an ultrasonic espresso process that uses high-frequency sound waves instead of hot water to produce espresso-strength coffee at room temperature. And, not only did coffee drinkers find it comparable to traditional espresso, but the brewing process cut energy use by up to 75%. An anonymous reader quotes a report from The Conversation: We have developed what we call an ultrasonic espresso: a room-temperature brewing process that uses high-frequency sound waves to extract the flavor, oils, aroma and caffeine from coffee grounds. The result is an espresso-strength coffee made in under three minutes, but needing far less energy than the conventional method. Saving up to 75% of energy by not heating the water is a minor benefit for home users or small coffee shops. But for companies making ready-to-drink coffee products at industrial scale, it could be very significant indeed. A concentrated room-temperature coffee could be used directly in bottled drinks, milk-based beverages or cold coffee products. It can also be shipped as a concentrate and diluted later. This would reduce not only energy use, but potentially processing time as well. The key to the new process is ultrasound. These are sound waves above the range of human hearing. In our system, a small metal device called a transducer presses against the side of a traditional espresso basket and makes it vibrate rapidly. Those vibrations move through the water and coffee grounds. This creates a phenomenon known as acoustic cavitation. Tiny bubbles form and collapse in the liquid. When these bubbles collapse near coffee particles, they produce microscopic jets and forces that act a little like scrubbing brushes. They pit and fracture the surface of the coffee grounds, helping flavor compounds, oils and caffeine move into the water much faster than they normally would at room temperature. In other words, ultrasound helps us replace heat with mechanical energy. [...] In earlier work, we used ultrasound to speed up cold brew dramatically. But the challenge in this project was different: could we produce something with the strength, body and intensity of espresso, without heating the water? To do that, we adjusted several variables. Brew ratio was one of the most important: how much water we used for each gram of coffee. Too much water and the drink becomes diluted; too little and extraction becomes difficult. Grind size also mattered. Finer grounds allowed us to extract flavor more rapidly. Finally, we tested how long the ultrasound should be applied. We found the sweet spot was about two-and-a-half to three minutes. Of course, making a concentrated coffee in the laboratory is one thing. The real test is whether people want to drink it. [...] For the espresso samples, participants could not reliably tell the traditional and ultrasonic versions apart. There were no significant differences in aroma, flavor, bitterness or overall liking. For filter coffee, the ultrasound version was actually preferred overall, with participants rating its bitterness more pleasantly.

Read more of this story at Slashdot.

Simon Ritter joined Sun Microsystems in 1996 and spent time working in both Java development and consultancy. He's now written an opinion piece for InfoWorld warning that "Between 2029 and 2032, every currently supported long-term support (LTS) version of Java will reach end-of-support within a single three-year window." That's Java 17 in 2029, Java 8 in 2030, Java 21 in 2031, and Java 11 in 2032... On paper, this looks like a manageable upgrade cycle. In practice, it creates a collision of timelines that most enterprises have failed to forecast. Organizations attempting to modernize incrementally — moving application by application, version by version — are operating on a model that the calendar has already rendered obsolete... [W]hen every major Java version expires in the same compressed window, sequential planning collapses. By the time this becomes obvious, organizations will be forced into reactive mode, making rushed decisions under extreme pressure. For organizations planning traditional stepwise upgrades — Java 8 to Java 11 to Java 17 to Java 21 — this convergence elevates a routine maintenance task into a structural crisis. Enterprises with large Java estates will be forced to upgrade multiple applications across multiple versions simultaneously to maintain security compliance and business continuity. "Parallel modernization requires parallel capacity — something most organizations haven't budgeted for," he points out. "This explains why traditional approaches struggle to scale."

Read more of this story at Slashdot.

A maximum-severity vulnerability in pac4j, an open-source library integrated into hundreds of software packages and repositories, poses a significant security threat, but has thus far received scant attention.

The defect in the Java security engine, which handles authentication across multiple frameworks, has not been exploited in the wild since code review firm CodeAnt AI published a proof-of-concept exploit last week. The company discovered the vulnerability and privately reported it to pac4j’s maintainer, which disclosed the defect and released patches for affected versions of the library within two days.

Some researchers told CyberScoop they are concerned about the vulnerability — CVE-2026-29000 — because it affects a widely deployed Java security engine that attackers can exploit with relative ease.

“A threat actor only needs to access a server’s public RSA key to attempt exploitation,” researchers at Arctic Wolf Labs said in an email. 

These public keys, which are shared openly, are used to encrypt data and enable identity authentication. Attackers can trigger the defect and bypass authentication by forging a JSON Web Token (JWT) or deploy raw JSON claims via JSON Web Encryption (JWE) in pac4j-jwt to break into a system with the highest privileges.

“It is currently too early into the lifecycle of this vulnerability to tell if it will materialize into a major threat but the fact that it is a vulnerability in a library makes it more challenging to assess the potential risk,” researchers at Arctic Wolf Labs said. “Downstream consumers of the library may end up needing to issue their own advisories, as we’ve seen with other similar vulnerabilities in the past.”

Amartya Jha, co-founder and CEO at CodeAnt AI, warned that anyone with basic JWT knowledge can achieve exploitation. The vulnerability is a “logic flaw that no pattern-matching scanner or rule-based static application security testing tool would surface, because there’s no single line of code that’s wrong.”

The downstream security risk, as is often the case with open-source software, is widespread. The authentication module for pac4j is integrated into multiple frameworks, including Spring Security, Play Framework, Vert.x, Javalin and others, Jha said.

Many organizations may not realize they depend on pac4j-jwt because it’s not always declared in build files, he added. CodeAnt said it has contacted hundreds of maintainers in the past week to warn them that their packages and repositories are impacted by the vulnerability, which has a CVSS rating of 10.

Researchers haven’t observed any additional PoC exploit code, but they noted the exploit path is easy to reproduce. 

“The conditions for exploitation are favorable,” Jha said. “It’s pre-authentication, requires no secrets, the PoC is public, and the attack surface includes any internet-facing application or API gateway using the affected configuration. The window between public PoC and patch adoption is where the risk is highest.”

The post Critical defect in Java security engine poses serious downstream security risks appeared first on CyberScoop.