Source
ghsa
An issue was discovered in RDoc 6.3.3 through 6.6.2, as distributed in Ruby 3.x through 3.3.0. When parsing `.rdoc_options` (used for configuration in RDoc) as a YAML file, object injection and resultant remote code execution are possible because there are no restrictions on the classes that can be restored. When loading the documentation cache, object injection and resultant remote code execution are also possible if there were a crafted cache. We recommend to update the RDoc gem to version 6.6.3.1 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead: * For Ruby 3.0 users: Update to `rdoc` 6.3.4.1 * For Ruby 3.1 users: Update to `rdoc` 6.4.1.1 * For Ruby 3.2 users: Update to `rdoc` 6.5.1.1 You can use `gem update rdoc` to update it. If you are using bundler, please add `gem "rdoc", ">= 6.6.3.1"` to your `Gemfile`. Note: 6.3.4, 6.4.1, 6.5.1 and 6.6.3 have a incorrect fix. We recommend to upgrade 6.3.4.1, 6.4.1.1, ...
An issue was discovered in StringIO 3.0.1, as distributed in Ruby 3.0.x through 3.0.6 and 3.1.x through 3.1.4. The `ungetbyte` and `ungetc` methods on a StringIO can read past the end of a string, and a subsequent call to `StringIO.gets` may return the memory value. This vulnerability is not affected StringIO 3.0.3 and later, and Ruby 3.2.x and later. We recommend to update the StringIO gem to version 3.0.3 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead: * For Ruby 3.0 users: Update to `stringio` 3.0.1.1 * For Ruby 3.1 users: Update to `stringio` 3.1.0.2 You can use `gem update stringio` to update it. If you are using bundler, please add `gem "stringio", ">= 3.0.1.2"` to your `Gemfile`.
# Summary Burn uses an unprotected C:\Windows\Temp directory to copy binaries and run them from there. This directory is not entirely protected against low privilege users. # Details When a bundle runs as SYSTEM user, Burn uses GetTempPathW which points to an insecure directory C:\Windows\Temp to drop and load multiple binaries. Standard users can hijack the binary before it's loaded in the application resulting in elevation of privileges. ``` icacls c:\windows\temp BUILTIN\Users:(CI)(S,WD,AD,X) BUILTIN\Administrators:(F) BUILTIN\Administrators:(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F) CREATOR OWNER:(OI)(CI)(IO)(F) ``` Built in users(non-administrators) have special permissions to this folder and can create files and write to this directory. While they do not have explicit read permissions, there is a way they can monitor the changes to this directory using ReadDirectoryChangesW API and thus figure out randomized folder names created inside this ...
# Summary Burn uses an unprotected C:\Windows\Temp directory to copy binaries and run them from there. This directory is not entirely protected against low privilege users. # Details When a bundle runs as SYSTEM user, Burn uses GetTempPathW which points to an insecure directory C:\Windows\Temp to drop and load multiple binaries. Standard users can hijack the binary before it's loaded in the application resulting in elevation of privileges. ``` icacls c:\windows\temp BUILTIN\Users:(CI)(S,WD,AD,X) BUILTIN\Administrators:(F) BUILTIN\Administrators:(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F) CREATOR OWNER:(OI)(CI)(IO)(F) ``` Built in users(non-administrators) have special permissions to this folder and can create files and write to this directory. While they do not have explicit read permissions, there is a way they can monitor the changes to this directory using ReadDirectoryChangesW API and thus figure out randomized folder names created inside this ...
### Summary There is a Path Traversal vulnerability in Attachments that allows attackers with admin rights to upload malicious files to other locations of the web root. ### PoC 1. In settings, the attachment location is vulnerable to path traversal and can be set to e.g ..\hacked  2. When the above is set, attachments files are now uploaded to e.g C:\Apps\XAMPP\htdocs\hacked instead of C:\Apps\XAMPP\htdocs\phpmyfaq\attachments 3. Verify this by uploading an attachment and see that the "hacked" directory is now created in the web root folder with the attachment file inside.   ### Impact Attackers can potentially upload malicious files outside the specified directory.
An issue in @thi.ng/paths v.5.1.62 and before allows a remote attacker to execute arbitrary code via the `mutIn` and `mutInManyUnsafe` components.
Versions of the package web3-utils before 4.2.1 are vulnerable to Prototype Pollution via the utility functions format and mergeDeep, due to insecure recursive merge. An attacker can manipulate an object's prototype, potentially leading to the alteration of the behavior of all objects inheriting from the affected prototype by passing specially crafted input to these functions.
paddlepaddle/paddle 2.6.0 allows arbitrary file read via paddle.vision.ops.read_file.
### Summary While examining the "App Link assetlinks.json file could not be found" vulnerability detected by MobSF, we, as the Trendyol Application Security team, noticed that a GET request was sent to the "/.well-known/assetlinks.json" endpoint for all hosts written with "android:host". In the AndroidManifest.xml file. Since MobSF does not perform any input validation when extracting the hostnames in "android:host", requests can also be sent to local hostnames. This may cause SSRF vulnerability. ### Details Example <intent-filter structure in AndroidManifest.xml: ``` <intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:host="192.168.1.102/user/delete/1#" android:scheme="http" /> </intent-filter> ``` We defined it as android:host="192.168.1.102/user/delete/1#". Here, the "#" character at the end of the hos...
A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS). Version 3.8.14.Final is expected to contain a fix.