diff --git a/osu.Game/IO/Archives/ZipArchiveReader.cs b/osu.Game/IO/Archives/ZipArchiveReader.cs
index 6bb2a314e7..8b9ecc7462 100644
--- a/osu.Game/IO/Archives/ZipArchiveReader.cs
+++ b/osu.Game/IO/Archives/ZipArchiveReader.cs
@@ -9,6 +9,7 @@ using System.IO;
 using System.Linq;
 using System.Text;
 using Microsoft.Toolkit.HighPerformance;
+using osu.Framework.Extensions;
 using osu.Framework.IO.Stores;
 using SharpCompress.Archives.Zip;
 using SharpCompress.Common;
@@ -54,12 +55,22 @@ namespace osu.Game.IO.Archives
             if (entry == null)
                 return null;
 
-            var owner = MemoryAllocator.Default.Allocate<byte>((int)entry.Size);
-
             using (Stream s = entry.OpenEntryStream())
-                s.ReadExactly(owner.Memory.Span);
+            {
+                if (entry.Size > 0)
+                {
+                    var owner = MemoryAllocator.Default.Allocate<byte>((int)entry.Size);
+                    s.ReadExactly(owner.Memory.Span);
+                    return new MemoryOwnerMemoryStream(owner);
+                }
 
-            return new MemoryOwnerMemoryStream(owner);
+                // due to a sharpcompress bug (https://github.com/adamhathcock/sharpcompress/issues/88),
+                // in rare instances the `ZipArchiveEntry` will not contain a correct `Size` but instead report 0.
+                // this would lead to the block above reading nothing, and the game basically seeing an archive full of empty files.
+                // since the bug is years old now, and this is a rather rare situation anyways (reported once in years),
+                // work around this locally by falling back to reading as many bytes as possible and using a standard non-pooled memory stream.
+                return new MemoryStream(s.ReadAllRemainingBytesToArray());
+            }
         }
 
         public override void Dispose()