## Leaking cached authenticated requests

### Impact
If you've been using one `MemoryCacheMethod` object in multiple instances of `Gw2WebApiClient` and are requesting authenticated endpoints with different access tokens, then you are likely to run into this bug.

When using an instance of `MemoryCacheMethod` and using it with multiple instances of `Gw2WebApiClient`, there's a possibility that cached authenticated responses are leaking to another request to the same endpoint, but with a different Guild Wars 2 access token. The latter request wouldn't start however, and would return the first cached response immediately. This means that the second response (or later responses) may contain the same data as the first response, therefore leaking data from another authenticated endpoint.

The occurence of this is limited however. The Guild Wars 2 API doesn't use the `Expires` header on most (if not all) authenticated endpoints. This header is checked when caching responses. If this header isn't available, the response isn't cached at all. You should still update to at least version 0.3.1 in order to be certain that it won't happen.

### Patches
This bug has been fixed in version 0.3.1. When using an authenticated endpoint, it will prepend the SHA-1 hash of the access token to the cache id.

### Workarounds
For version 0.3.0 and lower, you can use one separate instance of `MemoryCacheMethod` per `Gw2WebApiClient` if you need to use it.

### For more information
If you have any questions or comments about this advisory, you can open an issue in [the Gw2Sharp repository](https://github.com/Archomeda/Gw2Sharp) or contact me on [Discord](https://discord.gg/hNcpDT3).


The Recurly Client .NET Library before 1.0.1, 1.1.10, 1.2.8, 1.3.2, 1.4.14, 1.5.3, 1.6.2, 1.7.1, 1.8.1 is vulnerable to a Server-Side Request Forgery vulnerability due to incorrect use of "Uri.EscapeUriString" that could result in compromise of API keys or other critical resources.

Withdrawn, accidental duplicate publish.

Cross-site scripting (XSS) vulnerability in jQuery UI before 1.12.0 might allow remote attackers to inject arbitrary web script or HTML via the closeText parameter of the dialog function.

An attacker can forge signatures on arbitrary messages that will verify for any public key. This may allow attackers to authenticate as any user within the Stark Bank platform, and bypass signature verification needed to perform operations on the platform, such as send payments and transfer funds. Additionally, the ability for attackers to forge signatures may impact other users and projects using these libraries in different and unforeseen ways.

Directory traversal vulnerability in `CuteSoft_Client/CuteEditor/Load.ashx` in CuteSoft Components Cute Editor for ASP.NET allows remote attackers to read arbitrary files via a `..` (dot dot) in the file parameter.

### Impact
The CBOR library supports optional tags that enable CBOR objects to contain references to objects within them. Versions earlier than 4.0 resolved those references automatically. While this by itself doesn't cause much of a security problem, a denial of service can happen if those references are deeply nested and used multiple times (so that the same reference to the same object occurs multiple times), and if the decoded CBOR object is sent to a serialization method such as `EncodeToBytes`, `ToString`, or `ToJSONString`, since the objects referred to are expanded in the process and take up orders of magnitude more memory than if the references weren't resolved.

The impact of this problem on any particular system varies.  In general, the risk is higher if the system allows users to send arbitrary CBOR objects without authentication, or exposes a remote endpoint in which arbitrary CBOR objects can be sent without authentication.

### Patches
This problem is addressed in version 4.0 by disabling reference resolution by default.  Users should use the latest version of this library.

### Workarounds
Since version 3.6, an encoding option (`resolvereferences=true` or `resolvereferences=false`) in CBOREncodeOptions sets whether the CBOR processor will resolve these kinds of references when decoding a CBOR object.  Set `resolvereferences=false` to disable reference resolution.

In version 3.6, if the method used `CBORObject.Read()` or `CBORObject.DecodeFromBytes()` to decode a serialized CBOR object, call the overload that takes `CBOREncodeOptions` as follows:

    CBORObject.DecodeFromBytes(bytes, new CBOREncodeOptions("resolvereferences=false"));

In versions 3.5 and earlier, this issue is present only if the CBOR object is an array or a map.  If the application does not expect a decoded CBOR object to be an array or a map, it should check the CBOR object's type before encoding that object, as follows:

    if (cbor.Type != CBORType.Array && cbor.Type != CBORType.Map) {
       cbor.EncodeToBytes();
    }

Alternatively, for such versions, the application can use `WriteTo` to decode the CBOR object to a so-called "limited memory stream", that is, a `Stream` that throws an exception if too many bytes would be written.  How to write such a limited-memory stream is nontrivial and beyond the scope of this advisory.

    using(var stream = new LimitedMemoryStream(100000)) { // Limit to 100000 bytes
         cbor.WriteTo(stream);
         return stream.ToBytes();
    }

To check whether a byte array representing a CBOR object might exhibit this problem, check whether the array contains the byte 0xd8 followed immediately by either 0x19 or 0x1d.  This check catches all affected CBOR objects but may catch some non-affected CBOR objects (notably integers and byte strings).

### References

See the Wikipedia article [Billion laughs attack](https://en.wikipedia.org/wiki/Billion_laughs_attack) and the related issue in [Kubernetes](https://github.com/kubernetes/kubernetes/issues/83253).

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [the CBOR repository](https://github.com/peteroupc/CBOR).


Cross-site scripting (XSS) vulnerability in the default content option in jquery.ui.tooltip.js in the Tooltip widget in jQuery UI before 1.10.0 allows remote attackers to inject arbitrary web script or HTML via the title attribute, which is not properly handled in the autocomplete combo box demo.

Cross-site scripting (XSS) vulnerability in jQuery before 1.6.3, when using location.hash to select elements, allows remote attackers to inject arbitrary web script or HTML via a crafted tag.

Microsoft made an internal discovery of a security vulnerability in version 2.x of ASP.NET Core where
a specially crafted request can cause excess resource consumption in Kestrel.


### Impact
This update adds validation of the package ID and version during package download, in addition to the existing package signature validation.

### Patches

#### NuGet

The following NuGet.exe, NuGet.CommandLine, NuGet.Packaging, and NuGet.Protocol versions have been patched:

|Affected versions|Patched version|
|--|--|
|>= 4.9.0, <= 4.9.6|4.9.7|
|>= 5.11.0, <= 5.11.6|5.11.7|
|>= 6.8.0, <= 6.8.1|6.8.2|
|>= 6.11.0, <= 6.11.1|6.11.2|
|>= 6.12.0, <= 6.12.4|6.12.5|
|>= 6.14.0, <= 6.14.2|6.14.3|
|>= 7.0.0, <= 7.0.2|7.0.3|
|7.3.0|7.3.1|

#### .NET SDK

* .NET 8.0.126 SDK
* .NET 8.0.420 SDK
* .NET 9.0.116 SDK
* .NET 9.0.313 SDK
* .NET 10.0.106 SDK
* .NET 10.0.202 SDK

### Workarounds
N/A

### References
https://github.com/NuGet/NuGetGallery/security/advisories/GHSA-9r3h-v4hx-rhfr

### Credit
[splitline](https://x.com/_splitline_) with [DEVCORE](https://devco.re/)

The codebase raises code analysis warnings related to security, including CA3075, CA5366, CA5371, CA5368, CA5369, CA5372, CA5379, CA5350, and CA5351.

Most of these deal with disabling DTD processing in XML documents, but also includes cryptographic algorithm choices.

Cross-site scripting (XSS) vulnerability in DotNetNuke (DNN) before 6.2.9 and 7.x before 7.1.1 allows remote attackers to inject arbitrary web script or HTML via the __dnnVariable parameter to the default URI.

A denial of service vulnerability exists when ASP.NET Core improperly handles web requests, aka 'ASP.NET Core Denial of Service Vulnerability'.

Microsoft .NET Framework 2.0, 3.5, 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2 and 4.7 allow an attacker to bypass Enhanced Security Usage taggings when they present a certificate that is invalid for a specific use, aka ".NET Security Feature Bypass Vulnerability."

### Impact

The core Akka module depended on an old System.Configuration.ConfigurationManager version 4.7.0 which transitively depends on System.Common.Drawing v4.7.0. The System.Common.Drawing v4.7.0 is affected by a remote code execution vulnerability https://github.com/advisories/GHSA-ghhp-997w-qr28.

The real-world impact of this should be low, but users should be advised to upgrade to later versions of Akka.NET.

### Patches
_Has the problem been patched? What versions should users upgrade to?_

This issue is resolved in Akka.NET v1.4.46 and Akka.NET v1.5.0-alpha3.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

You might be able to explicitly reference System.Configuration.ConfigurationManager's NuGet package and upgrade to 6.0.1 or later without upgrading Akka.NET, but it's probably best to upgrade Akka.NET itself.

### References
_Are there any links users can visit to find out more?_

Original issue: https://github.com/akkadotnet/akka.net/issues/6226
MSFT advisory: https://github.com/advisories/GHSA-ghhp-997w-qr28

### For more information
If you have any questions or comments about this advisory:

* Open an issue in [the Akka.NET repository](https://github.com/akkadotnet/akka.net/issues/new)
* Contact us on [the Akka.NET Discord](https://discord.gg/GSCfPwhbWP)


### Impact

When this library is used to deserialize messagepack data from an untrusted source, there is a risk of a denial of service attack by an attacker that sends data contrived to produce hash collisions, leading to large CPU consumption disproportionate to the size of the data being deserialized.

This is similar to [a prior advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf), which provided an inadequate fix for the hash collision part of the vulnerability.

### Patches

The following steps are required to mitigate this risk.

1. Upgrade to a version of the library where a fix is available. If upgrading from v1, check out [our migration guide](https://github.com/MessagePack-CSharp/MessagePack-CSharp/blob/master/doc/migration.md).
1. Review the steps in [this previous advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf) to ensure you have your application configured for untrusted data.

### Workarounds

If upgrading MessagePack to a patched version is not an option for you, you may apply a manual workaround as follows:

1. Declare a class that derives from `MessagePackSecurity`.
2. Override the `GetHashCollisionResistantEqualityComparer<T>` method to provide a collision-resistant hash function of your own and avoid calling `base.GetHashCollisionResistantEqualityComparer<T>()`.
3. Configure a `MessagePackSerializerOptions` with an instance of your derived type by calling `WithSecurity` on an existing options object.
4. Use your custom options object for all deserialization operations. This may be by setting the `MessagePackSerializer.DefaultOptions` static property, if you call methods that rely on this default property, and/or by passing in the options object explicitly to any `Deserialize` method.

### References

- Learn more about best security practices when reading untrusted data with [MessagePack 1.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp/tree/v1.x#security) or [MessagePack 2.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp#security).
- The .NET team's [discussion on hash collision vulnerabilities of their `HashCode` struct](https://github.com/GrabYourPitchforks/runtime/blob/threat_models/docs/design/security/System.HashCode.md) (or in [the pull request that merges this into the dotnet org](https://github.com/dotnet/runtime/pull/108864)).

### For more information

If you have any questions or comments about this advisory:

* [Start a public discussion](https://github.com/MessagePack-CSharp/MessagePack-CSharp/discussions)
* [Email us privately](mailto:andrewarnott@live.com)

Microsoft is aware of a denial of service vulnerability in ASP.NET Core when a malformed request is terminated. An attacker who successfully exploited this vulnerability could cause a denial of service attack.

The update addresses the vulnerability by correcting how ASP.NET Core handles such requests.


### Impact
A cross-site scripting (XSS) vulnerability was discovered in the URL sanitization logic of the core parser. The vulnerability allowed arbitrary JavaScript execution when inserting a specially crafted piece of content into the editor using the clipboard or APIs. This impacts all users who are using TinyMCE 5.5.1 or lower.

### Patches
This vulnerability has been patched in TinyMCE 5.6.0 by improved URL sanitization logic.

### Workarounds
To work around this vulnerability, either:
- Upgrade to TinyMCE 5.6.0 or higher
- Manually sanitize `iframe`, `object` and `embed` URL attributes using a [TinyMCE node filter](https://www.tiny.cloud/docs/api/tinymce.html/tinymce.html.domparser/#addnodefilter).
- Disable `iframe`, `object`, and `embed` elements in your content using the [invalid_elements](https://www.tiny.cloud/docs/configure/content-filtering/#invalid_elements) setting.

#### Example: Sanitizing using a node filter
```js
editor.parser.addNodeFilter('iframe,object,embed', function(nodes) {
  nodes.forEach(function(node) {
    if (node.attributes) {
      node.attributes.forEach(function(attr) {
        var name = attr.name;
        var value = attr.value;
        // Sanitize the attribute value here or remove it entirely
        var sanitizedValue = ...;
        node.attr(name, santizedValue);
      });
    }
  });
});
```

#### Example: Using invalid_elements
```js
invalid_elements: 'iframe,object,embed'
```

### Acknowledgements
Tiny Technologies would like to thank Aaron Bishop at SecurityMetrics for discovering this vulnerability.

### References
https://www.tiny.cloud/docs/release-notes/release-notes56/#securityfixes

### For more information
If you have any questions or comments about this advisory:
* Open an issue in the [TinyMCE repo](https://github.com/tinymce/tinymce/issues)
* Email us at [infosec@tiny.cloud](mailto:infosec@tiny.cloud)

CVE-2020-16017: Use after free in site isolation

- https://chromereleases.googleblog.com/2020/11/stable-channel-update-for-desktop_11.html
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16017

Google is aware of reports that exploits for CVE-2020-16013 and CVE-2020-16017 exist in the wild.

There is currently little to no public information on the issue other than it has been flagged as `High` severity.

This vulnerability was reported to the personnummer team in June 2020. The slow response was due to locked ownership of some of the affected packages, which caused delays to update packages prior to disclosure.

The vulnerability is determined to be low severity.

### Impact

This vulnerability impacts users who rely on the for last digits of personnummer to be a _real_ personnummer.  

### Patches

The issue have been patched in all repositories. The following versions should be updated to as soon as possible:

[C#](https://github.com/advisories/GHSA-qv8q-v995-72gr) 3.0.2  
D 3.0.1  
[Dart](https://github.com/advisories/GHSA-4xh4-v2pq-jvhm) 3.0.3  
Elixir 3.0.0  
[Go](https://github.com/advisories/GHSA-hv53-vf5m-8q94) 3.0.1  
[Java](https://github.com/advisories/GHSA-q3vw-4jx3-rrr2) 3.3.0  
[JavaScript](https://github.com/advisories/GHSA-vpgc-7h78-gx8f) 3.1.0  
Kotlin 1.1.0  
Lua 3.0.1  
[PHP](https://github.com/advisories/GHSA-2p6g-gjp8-ggg9) 3.0.2  
Perl 3.0.0  
[Python](https://github.com/advisories/GHSA-rxq3-5249-8hgg) 3.0.2  
[Ruby](https://github.com/advisories/GHSA-vp9c-fpxx-744v) 3.0.1  
[Rust](https://github.com/advisories/GHSA-28r9-pq4c-wp3c) 3.0.0  
Scala 3.0.1  
Swift 1.0.1  

If you are using any of the earlier packages, please update to latest.

### Workarounds

The issue arrieses from the regular expression allowing the first three digits in the last four digits of the personnummer to be
000, which is invalid. To mitigate this without upgrading, a check on the last four digits can be made to make sure it's not
000x.

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Personnummer Meta](https://github.com/personnummer/meta/issues)
* Email us at [Personnummer Email](mailto:security@personnummer.dev)

SwaggerUI supports displaying remote OpenAPI definitions through the `?url` parameter. This enables robust demonstration capabilities on sites like `petstore.swagger.io`, `editor.swagger.io`, and similar sites, where users often want to see what their OpenAPI definitions would look like rendered.

However, this functionality may pose a risk for users who host their own SwaggerUI instances. In particular, including remote OpenAPI definitions opens a vector for phishing attacks by abusing the trusted names/domains of self-hosted instances.

An example scenario abusing this functionality could take the following form:
- `https://example.com/api-docs` hosts a version of SwaggerUI with `?url=` query parameter enabled.
- Users will trust the domain `https://example.com` and the contents of the OpenAPI definition.
- A malicious actor may craft a similar OpenAPI definition and service that responds to the defined APIs at `https://evildomain`.
- Users mistakenly click a phishing URL like `https://example.com/api-docs?url=https://evildomain/fakeapi.yaml` and enters sensitive data via the "Try-it-out" feature.

We do want to stress that this attack vector is limited to scenarios that actively trick users into divulging sensitive information. The ease of this is highly contextual and, therefore, the threat model may be different for individual users and organizations. It is *not* possible to perform non-interactive attacks (e.g., cross-site scripting or code injection) through this mechanism.

### Resolution 
We've made the decision to [disable query parameters (#4872)](https://github.com/swagger-api/swagger-ui/issues/4872) by default starting with SwaggerUI version `4.1.3`. Please update to this version when it becomes available (**ETA: 2021 December**). Users will still be able to be re-enable the options at their discretion. We'll continue to enable query parameters on the Swagger demo sites.

### Workaround
If you host a version of SwaggerUI and wish to mitigate this issue immediately, you are encouraged to add the following custom plugin code:

```js
SwaggerUI({
  //  ...other configuration options,
  plugins: [function UrlParamDisablePlugin() {
    return {
      statePlugins: {
        spec: {
          wrapActions: {
            // Remove the ?url parameter from loading an external OpenAPI definition.
            updateUrl: (oriAction) => (payload) => {
              const url = new URL(window.location.href)
              if (url.searchParams.has('url')) {
                url.searchParams.delete('url')
                window.location.replace(url.toString())
              }
              return oriAction(payload)
            }
          }
        }
      }
    }
  }],
})
```

### Future UX work

Through the exploration of this issue, it became apparent that users may not be aware to which web server the Try-it-out function will send requests. While this information is currently presented at the top of the page, understanding may improve by displaying it closer to the "Execute" button where requests are actually made. We'll be exploring these UX improvements over the coming months and welcome community input. Please create a Feature Request under the GitHub Issue tab to start a conversation with us and the community.

## Reflected XSS attack

**Warning** in versions < 3.38.0, it is possible to combine the URL options (as mentioned above) with a vulnerability in DOMPurify (https://www.cvedetails.com/cve/CVE-2020-26870/) to create a reflected XSS vector. If your version of Swagger UI is older than 3.38.0, we suggest you upgrade or implement the workaround as mentioned above.


An elevation of privilege vulnerability exists when a ASP.NET Core web application, created using vulnerable project templates, fails to properly sanitize web requests, aka 'ASP.NET Core Elevation Of Privilege Vulnerability'.

High CVE-2020-16013: Inappropriate implementation in V8. 

- https://chromereleases.googleblog.com/2020/11/stable-channel-update-for-desktop_11.html
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16013

Google is aware of reports that exploits for CVE-2020-16013 and CVE-2020-16017 exist in the wild.

There is currently little to no public information on the issue other than it has been flagged as `High` severity.

A vulnerability was discovered in the OPC UA .NET Standard Stack that allows a malicious client to trigger a stack overflow exception in a server that exposes an HTTPS endpoint.

We have identified that this project contains an out-of-date version of the Public Suffix List (https://publicsuffix.org/). We are carrying out research to identify the potential impacts of using old versions of the Public Suffix List, and we intend to publish our results in academic conferences and journals. Our results will become publicly available after 21 days; this provides time to update your project with an up-to-date version of the Public Suffix List.

GitHub repository: gsemac/Gsemac.Common
Public Suffix List path: src/Gsemac.Net/Resources/public_suffix_list.dat

The Public Suffix List is regularly updated (generally a few times per week), and to ensure that the correct privacy boundaries are maintained between websites, applications that use it should routinely fetch an updated copy. If new suffixes are added to the list, and an old list is then used, privacy boundaries will not be constructed correctly, allowing for data (e.g., cookies) to be set incorrectly, potentially harming privacy.

There is further guidance on how the Public Suffix List should be used in ICANN’s “Advisory on the Use of Static TLD / Suffix Lists” at https://www.icann.org/en/system/files/files/sac-070-en.pdf.

If you have any questions about our research, or about usage of the Public Suffix List, please reply via e-mail to [sm@smcquistin.uk](mailto:sm@smcquistin.uk).

Google is aware that an exploit for CVE-2023-5217 exists in the wild.

Description
Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

References
- https://www.cve.org/CVERecord?id=CVE-2023-5217
- https://nvd.nist.gov/vuln/detail/CVE-2023-5217


DotNetNuke before 4.8.2, during installation or upgrade, does not warn the administrator when the default (1) ValidationKey and (2) DecryptionKey values cannot be modified in the web.config file, which allows remote attackers to bypass intended access restrictions by using the default keys.

An issue in System.Linq.Dynamic.Core versions before v.1.6.0 allow remote access to properties on reflection types and static properties/fields.

CVE ID↕	Published↕	CVSS↓
GHSA-4vr3-9v7h-5f8v	Jun 18, 2019	N/A
GHSA-xpwp-rq3x-x6v7	Oct 16, 2018	N/A
GHSA-g8q2-24jh-5hpc	Jul 27, 2018	N/A
GHSA-9wx7-jrvc-28mm	Nov 8, 2021	N/A
GHSA-w327-wq28-3vmf	May 2, 2022	N/A
GHSA-cxw4-9qv9-vx5h	Sep 30, 2019	N/A
GHSA-qqxp-xp9v-vvx6	Oct 24, 2017	N/A
GHSA-579v-mp3v-rrw5	May 14, 2022	N/A
GHSA-3m2r-q8x3-xmf7	Oct 16, 2018	N/A
GHSA-g4vj-cjjj-v7hg	Apr 14, 2026	N/A
GHSA-fcpv-w245-r2q7	Apr 14, 2026	N/A
GHSA-rvrj-j7cc-236p	May 17, 2022	N/A
GHSA-23cv-jh4v-vffm	May 24, 2022	N/A
GHSA-ch6p-4jcm-h8vh	Oct 16, 2018	N/A
GHSA-gpv5-rp6w-58r8	Nov 22, 2022	N/A
GHSA-4qm4-8hg2-g2xm	Oct 17, 2024	N/A
GHSA-cgpw-2gph-2r9g	Oct 16, 2018	N/A
GHSA-w7jx-j77m-wp65	Jan 6, 2021	N/A
GHSA-gvqv-779r-4jgp	Nov 27, 2020	N/A
GHSA-qv8q-v995-72gr	Sep 9, 2020	N/A
GHSA-qrmm-w75w-3wpx	Dec 9, 2021	N/A
GHSA-xr8f-59pp-rxxh	May 24, 2022	N/A
GHSA-x7fx-mcc9-27j7	Nov 27, 2020	N/A
GHSA-6fp8-cxc9-4fr9	Jun 17, 2022	N/A
GHSA-w4x6-hh3x-wjrx	Dec 11, 2023	N/A
GHSA-4c29-gfrp-g6x9	Oct 5, 2023	N/A
GHSA-grw3-hjjm-5cjm	May 14, 2022	N/A
GHSA-4cv2-4hjh-77rx	Jan 21, 2025	N/A

Know every vulnerability
before it knows you.

nuget CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerabilitybefore it knows you.

nuget CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerability
before it knows you.