-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major
-
None
-
Affects Version/s: 10.0.1, 10.2.0
-
Component/s: None
-
Security Level: Jimmy
-
None
-
None
Steps to Reproduce
Run attached sample project with mvn jetty:run
go to
http://localhost:8080/zk10contextpathhashsign%23%23001/index.zul
Current Result
http://localhost:8080/zk10contextpathhashsign%2523%2523001/zkau/web/b33ca6ab/js/zk.wpd net::ERR_ABORTED 404 (Not Found)
Expected Result
No error
Debug Information
SSRF protection finds the % signs in %23%23001 and replaces them by %25 (encodes the hash sign).
Also affects other workflows.
In some linux servers, using this type of war file name
myWarFile##001.war will create a servlet located at
myWarFile##001
with a web context located at
myWarFile
This is used for zero-downtime deployements. (if another version myWarFile##002 is deployed, 001 will be undeployed once all sessions are migrated to 002)
Causes error such as:
26-Aug-2025 17:07:14.327 WARNING [http-nio-8084-exec-5] org.zkoss.util.resource.AbstractLoader.getLastModified The connection cannot be closed
java.nio.file.NoSuchFileException: /tmp/maxim/apache-tomcat-11.0.10/webapps/myWar%23%23001/WEB-INF/lib/zweb.jar
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:148)
at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
at java.base/java.nio.file.Files.readAttributes(Files.java:1849)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1279)
at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:710)
at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:243)
at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:172)
at java.base/java.util.jar.JarFile.<init>(JarFile.java:345)
at java.base/sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:103)
at java.base/sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:72)
at java.base/sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:168)
at java.base/sun.net.www.protocol.jar.JarFileFactory.getOrCreate(JarFileFactory.java:91)
at java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:110)
at java.base/sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:153)
at org.zkoss.util.resource.AbstractLoader.getLastModified(AbstractLoader.java:56)
at org.zkoss.util.resource.ResourceCache$Info.load(ResourceCache.java:229)
at org.zkoss.util.resource.ResourceCache$Info.<init>(ResourceCache.java:202)
at org.zkoss.util.resource.ResourceCache.get(ResourceCache.java:134)
due to org.zkoss.util.resource.AbstractLoader.getLastModified(K) invoking org.zkoss.util.URLs.sanitizeURL(URL).
Since the path to the resource contains # (already encoded as %23), the application fails to load the resources with exception above
Workaround
-
- relates to
-
-
- Closed
-