Hi @jw ,

Can you share us a copy of your database bacakup or export?

I created a ticket that will allow you to upload this: EDO-13159

Once we have that, wecan investigate this further.

Thanks,
Alana

Hi @seanl_4808 ,

Like SAML, OIDC is not intended for developer/CLI tools, but desktop-based applications. I'm not aware of any client-tooling that supports or plans to support OIDC, so there's no sense in having a sever-based tool supported OIDC.

API keys are considered the modern/secure solution. The reason that WIA/OIDC is considered less secure comes down to reducing the attack surface. A rouge user or process would be able to do very little with a limited-access ProGet API key, compared with domain credentials.

Thanks,
Alana

Hi @sai.pabbareddy ,

A 500 is an system error and would be logged under Admin > Diagnostic Center. It's possible there was system overload, network issues, who knows. I wouldn't worry about it.

A 403 is a permission error that would be caused by configuration. It sounds like you resolved it by changing/modifying configuration, waiting for a cache to clear, etc.

Thanks,
Alana

Hi @sai.pabbareddy ,

There is no rule, but I believe admins are encouraged to create one as part of the "onboarding" process when creating feeds, at some point.

Can you point to the documentation that shows that? We will clarify the documentation.

Thanks,
Alana

Hi @sai.pabbareddy ,

This is by design; download blocking is not supported on Docker feeds because it creates a very poor deployment experience, in particular with "fat manifest" images. There is simply no way to communicate to the end-user (typically a devops/release engineer) that an image is blocked, and they just end up getting random and indecipherable errors from the client.

This happens at deploy time, so it causes huge panic. Blocker tickets get opened. Everyone "blames" the tools and no one understands why.

Keep in mind that Docker containers are constantly deployed, so you jus tend up with random production deploy failures from "yet another" overrated vulnerability that just happens to pop-in the system.

Compare this to packages, which are consumed at build-time only and "blocking" only causes a poor developer experience (rarely production failures).

Please use pgutil containers audit instead:
https://docs.inedo.com/docs/proget/api/containers/audit-image

Thanks,
Alana

Hi @sai.pabbareddy,

[1] Here is some more information on PVRS vs CVSS:
https://guides.inedo.com/vulnerability-management/cvss-pvrs/

Long story short, PVRS is designed for OSS dependencies and analyzes risk differently, in particular taking into account the custom risk profile you enter in ProGet (under Policies).

[2] The NU1902 advisory comes from a vulnerability.base.json file that is cached both on the client end and ProGet end; you need to clear the http caches on NuGet (which you did), and ProGet will invalidate it about once an hour. You can force invalidation by restarting the service (Admin > Service) or manually assessing vulnerabilities (Admin > Vulnerabilities > Reassess), but that should only appear for test purposes.

In a normal workflow the client will aggressively cache this file, and there's no real harm in having outdated information when following our recommended workflows.

On that note.... we do NOT recommend you block downloads. It will actually lower your organization's security posture, not improve it. Please review this to learn how to "contain" properly: https://guides.inedo.com/vulnerability-management/containment/

Thank you,
Alana

Hi @amy.j ,

I don't think the API has changed, but I suspect it has something to do with multi-file packages, and the way that the aggregate result is presented.

But I'd like to confirm that. Can you run the following script using the package you're looking at, and share the resulting output?

import requests
import os

BASE_URL = "https://proget.example.com"
API_KEY = os.environ.get("PROGET_API_KEY")
FEED = "pypi-proxy-test"
package = "charset_normalizer"
version = "3.5.1"

headers = {
    "X-ApiKey": API_KEY
}


metadata_response = requests.get(
    f"{BASE_URL}/api/packages/{FEED}/metadata?name={package}&version={version}",
    headers=headers,
)
print(metadata_response.json())

for artifact in metadata_response.json()["artifacts"]:
    print(artifact["qualifier"])
    
    response = requests.post(
        f"{BASE_URL}/api/packages/{FEED}/audit?name={package}&version={version}&qualifier={artifact['qualifier']}",
        headers=headers,
    )

    print(response.json())

Thanks,
Alana

Hi @sai.pabbareddy ,

I'm not really sure what question you're asking?

CVE-2025-26646 has been in Inedo's database as PGV-2535204 since May 13, 2025.

However, under the default risk profile in ProGet, we rate this a Category 1 since there is effectively no risk posed by this vulnerability. It requires a malicious inside actor with access to modify the source code -- which is not a realistic threat actor.

As such, ProGet will not not "spam" developers via the NuGet client with needless warnings. This is all by design.

You can learn more about that here: https://guides.inedo.com/vulnerability-management/categories/

Thanks,
Alana

Hi @carl.westman_8110 ,

It looks like several have, since the Next Run Time is in the past for several of them.

I would just hit the "Restart Service" button to resolve this.

Thanks,
Alana

Hi @certificatemanager_4002 ,

The API is a bit harder to use than just pgutil, so I'd suggest to use pgutil instead and it's easy to make a simple mistake like encoding something incorrectly. Without studying your code and having direct access to your ProGet instance, I cannot tell you what the issue is.

But, since pgutil works we know the API is fine; here is the code that pgutil uses to delete the user:
https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/ProGetClient.cs#L744

would suggest to use a local proxy tool like fiddler classic, proxyamn, postman, etc., that can capture and analyze local HTTP traffic so you can see the difference between what your code is doing and what pgutil is doing.

Thanks,
Alana

Hi @rob ,

When using the the subject name, the X509NameType.SimpleName is extracted and compared. Here's the specific logic:

x509Store.Certificates.Where(c => c.GetNameInfo(X509NameType.SimpleName, false).Equals(config.Subject, StringComparison.OrdinalIgnoreCase)).OrderByDescending(c => c.NotAfter).FirstOrDefault()

So if the "wrong" Server1 is being selected, I'm guessing it shares the same simple name.

In scenarios like this, we recommend renaming the certificate (e.g. ProGetSsl), using a file, or the thumbprint.

Thanks,
Alana

Hi @certificatemanager_4002 ,

Maybe you're attempting to delete a principal that's not a user, such as a group or Anonymous or something.

In any case, the API uses the exact same code as the UI; I'll share it:

case "delete":
    EnsureMethod(context, "POST", "DELETE");
    var userName = context.Request.QueryString["user"];
    if (string.IsNullOrEmpty(userName))
        throw new HttpException(400, "Expected user query argument.");
    DB.Users_DeleteUser(userName);
    break;

Here is the UI code for the button click on the /administration/security/users/delete-user?userName=asdfasdf page:

var btnDelete = new PostBackButtonLink(
    "Yes, Delete User",
    () =>
    {
        DB.Users_DeleteUser(this.UserName);
        WebUserContext.ClearCache();
        this.CloseModalWindow(false);
    }
);

Your request might not be reaching the endpoint; I would attempt to do DELETE /api/security/users/delete?something=nothing to make sure you're getting a 400 error.

Hope that helps.
Alana

Hi @federico.conoscenti ,

Universal Package do support arbitrary metadata in the manifest file, and ProGet will display that on the UI. It's technically possible to add arbitrary metadata to other package files as well, although obviously ProGet could never know about or display that. However this metadata is not intended for searching or indexing.

ProGet does not support "arbitrary, server-side metadata" for any package types. In other words, you cannot simply "tag" or "annotate" otherwise packages after they've been added to ProGet.

This is intentional and by design, as it keeps the metadata contained to the manifest file (which is stored within the package file itself), which effectively makes it "cryptographically sealed" and cannot be tampered with.

So, as you migrate from Artifactory, you'll need to change your workflows to support a more modern, package mindset. In case you haven't seen it already, we have a Migrating from Artifactory to ProGet Guide that you may find helpful.

Best,
Alana

Hi @seanl_4808 ,

First and foremost, we recommend that you move away from Windows Integrated Authentication as Microsoft is discontinuing the technology and move to a modern, more secure technology. It's only going to be a matter of time before WIA stops working altogether due to bugs or removal of support by us or Microsoft.

That said, WIA is pretty limited as you can see. However, you can try configuring IIS as a reverse proxy that forwards https://hostname:443 to http/:*:8624; that may also make certificate management easier. We don't have a guide to set that up, however; I'v eonly heard of one customer who made it work somehow with WIA.

Thanks,
Alana

Hi @certificatemanager_4002 ,

My guess is there's some kind of typo with the username you're sending.

The name is not validated before attempting to delete, which means you can type in any string and a 200 will be returned.

If you don't send an arggument, you will get an error however.

I would also try using pgutil security users delete to see if that helps:
https://docs.inedo.com/docs/proget/api/security/users/delete

Thanks,
Alana

Hi @amy.j ,

This sounds like it's related to PG-3356, which is targeted for this week's maintenance release.

Can you upgrade to 2026.10 (once released) and give it a sot after that?

Thanks,
Alana

Hi @geraldizo_0690,

We haven't dug in just yet. We're assuming there's a long-standing issue with the URL Generator (as you mention), but it's not so straight-forward and seems to require a code change, etc.

We plan to get it in an upcoming maintenance release and will update as soon as we know which one specifically. In the meantime, I'd make sure you're able to upgrade to the latest version (i.e. ProGEt 2026).

Thanks,
Alana

Hi @msicc ,

I would definitely budget for ProGet Enterprise, as you 100 devs is generally where a load-balanced setup really starts to make sense. It depends on so many factors, but a handful of simultaneous package restores can yield thousands of simultaneous requests by machines more powerful than a typical ProGet server (i.e. developer workstations), each which generally has to reach to connectors.

That basically leads to a DDoS against your server. See How to Prevent Server Overload in ProGet to learn more.

As for active builds,

• a build is an entry under SCA > Projects > Builds; typically one build per CI run, but you might do more
• only the first 1000 active builds are analyzed; so everything else will show as inconclusive
• you can configure different stages to automatically archive other builds upon promotion; this is what we recommend

To estimate, I would do a multiple of your active, nonlibrary projects. It's certainly feasible to have multiple active builds per project (e.g. one in build stage, one in testing, another in production), but a lot of that depends on your configuration.

Hope that helps,
Alana

Hi @amy.j ,

If the package is already cached in ProGet, then the publish date is already set. So, i would make sure to delete the package and try it again.

Otherwise, can you share more specifics? That way we can create a reproduction case.

Thanks,
Alana

@Nils-Nilsson thank you so much!

We've published a new version of pgutil with these commands added :)