IIS and CVE-2026-49975
Hello IIS Team, our SOC Team informed us about the CVE-2026-49975 vulnerability in MS IIS. I could'nt found any patch for this. So my question is - are there any plans for for a patch / hotfix or what can we do to fix this? Greetings Rene Source: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb
IIS on Windows 10 no longer serving my websites
My websites were working, i.e. I could access them on my mobile phone. But something has happened abd they are not longer accessible - "NOT FOUND" I have checked: The bindings - https, correct domain name Both web sites are started. I have done ISSRESET. Checked my A records in Webcentral account. So what else do I need to check? Is there a specific IIS troubleshooter available that I can download and run?
HTTPS Reverse Proxy on IIS 10 – External Access Fails (Timeout) Although Local Requests Work
Hello everyone, I’m currently facing an issue with an IIS 10 reverse proxy configuration on Windows Server, and I would really appreciate your guidance. Environment Windows Server IIS 10 Application Request Routing (ARR) + URL Rewrite enabled Backend application running on: http://localhost:8080/ http://localhost:8080/login Public domain: https://lojistik.abc.com.tr What I want to achieve I want users to access the backend web application through the following URL: https://lojistik.abc.com.tr/LMYS/login Internally, IIS should proxy this to: http://localhost:8080/login What works The backend application is accessible without issues: http://localhost:8080/login From the server itself, reverse proxy works: Invoke-WebRequest "https://lojistik.abc.com.tr/LMYS/login" → StatusCode: 200 (success) What does NOT work From any client machine, the following request results in a timeout: https://lojistik.abc.com.tr/LMYS/login Browser shows connection timeout. No entry appears in IIS logs for external requests to /LMYS/.... Tests performed ▪ netstat -ano | findstr :443 on the server → Port 443 is listening ▪ DNS resolves correctly: lojistik.abc.com.tr → 10.6.130.90 ▪ Reverse proxy rule on IIS is correctly configured under the HTTPS binding site: Pattern: ^LMYS(/.*)?$ Rewrite to: http://localhost:8080{R:1} ▪ ARR Server Proxy is enabled. Key observation Requests from the server itself succeed (reverse proxy returns 200), but external clients always time out, which suggests that the HTTPS traffic is not reaching IIS at all (likely blocked or not NAT-forwarded on the network path). Question What could cause HTTPS (port 443) traffic to reach IIS locally, but external requests to the same port to hang indefinitely? Any guidance would be greatly appreciated. Thank you in advance. Best regards,Binding a website that already uses required port.
Hello devs, I hope you are having a great day. I have already developed a website that runs on port 8081 in localhost. When i start a new site in IIS and set 8081 as the port in the bind section(which is already open via the website), I receive the error that the port is already in use. My question is how can I connect my domain to the local host and specified port in IIS or any other application. The IIS has a default website(which brings the welcome page up) and by using that the connection between domain and server is assured(name servers are set and ready). If only the IIS could relay all traffic to the localhost and port 8081 of the server, my problem would be solved. I have attached some pictures for better understanding. Thank you in advance Best wishes, Sahand -As you see in this picture my website has started and working in the specified IP and port. ,-In this picture while binding the new website to port 8081 the IIS refuses to start the site with this error(port 8081 is already in use by my website).IIS URL Rewrite Rule Not Working: Resolving 'HTTP Error 404.4 - Not Found' Issues.
Issue Most of you have encountered situations where you have used IIS URL Rewrite to redirect traffic from one site to another. But in some cases, rewrite rules fail to work as expected and returns 'HTTP Error 404.4 - Not Found'. The 404.4 status code means no handler configured. Which means the file name extension of the requested URL doesn't have a handler that is configured to process the request on the Web server. For example you have two sites hosted in IIS. Site1 bind with port 81 and Site2 bind with port 82. The requirement is to rewrite all the request coming to Site1 (port:81) should rewrite to Site2 (port:82). The below rule is configured - <system.webServer> <rewrite> <rules> <rule name="RewriteToPort81" stopProcessing="true"> <match url="^.*$" /> <action type="Rewrite" url="http://localhost:82/{R:0}" appendQueryString="true" /> </rule> </rules> </rewrite> </system.webServer> Solution First you need to check if the correct module is installed in IIS. To check this go to IIS Manager and open the Modules. Within the Modules check if the correct URL Rewrite module is installed. You can get the latest IIS URL Rewrite module from this link URL Rewrite : The Official Microsoft IIS Site If the correct module is installed as highlighted above, the next thing you check the Failed Request Tracing logs for the request. And verify if the correct rule is invoked and it updates the URL to new one. Here in this case you can see "RewriteToPort82" rule is invoked and it changed the request URL to http://loalhost:82/. Also verify if the HttpStatus="404" and HttpSubStatus="4". To remediate the issue, go to IIS Manager, open Application Request Routing Cache module and open Server Proxy Settings form the right-hand Actions pane. Within the Server Proxy Settings you will find an option to enable proxy. Check the Enable proxy checkbox and click apply form the right-hand Actions pane as pointed in the below picture. After this you need to restart IIS. This should resolve the URL rewrite issue. To know more about URL rewrite in IIS you can follow this article - Using the URL Rewrite Module | Microsoft LearnHow to Configure and Collect Schannel and CAPI2 Logs
CAPI2 log is a diagnostic log in Windows that tracks cryptographic operations. It track events related to certificate validation, key exchange. It also record how Windows and applications use cryptographic algorithms for securing data. This is crucial for diagnosing issues with SSL/TLS, digital signatures, and other encryption-related processes. CAPI2 logs are particularly useful for diagnose security-related problems in Windows systems. When troubleshooting issues related to cryptographic operations in Windows, it may be necessary to enable and collect logs for both Schannel and CAPI2. This article will help you to configure and collect these logs for diagnostic purposes.IIS port problem
Hi everybody! My company would like to use MantisBT and i got the task to setup mantis but i have some problem with it. I would like to run MantisBT on port 443 (https) but one application already use this port. (This application isn't based on IIS). The server which should run MantisBT has two network cards and using Windows Server 2019. The first (x.x.x.1) is used by the necessary monitoring application, the other one (x.x.x.2) should used by MantisBT. The problem is if i bind x.x.x.2 IP to port 443 than i got an error message: The process cannot access the file because: it is being used by another process.(Exception from HRESULT: 0x80070020) Any idea what should i do? Can you give me step by step advice? Thank you. Have a nice day! PN
How to Properly Configure IIS Reverse Proxy for ASP.NET Core Applications Secured with Entra ID
If you’ve ever worked on an ASP.NET Core application protected with Entra ID, you might have encountered an issue where the backend server URL appears as the redirect URI instead of the IIS Reverse Proxy URL. This is because ASP.NET Core applications use the backend server’s hostname to generate the redirect URI. While this behavior is the default, it can be problematic. While you can work around this by manually setting the redirect URI to the ARR/IIS Reverse Proxy endpoint in your code as follows: builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme) .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd")); builder.Services.Configure<OpenIdConnectOptions>(options => { options.Events.OnRedirectToIdentityProvider = context => { context.ProtocolMessage.RedirectUri = "https://arr.local.lab"; return Task.FromResult(0); }; }); It isn’t the most elegant solution, especially in environments where configuration changes might often be required. Instead, using Forwarded Headers offers a cleaner, more scalable approach. In this post, I’ll walk you through how to resolve this issue using Forwarded Headers. ASP.NET Core provides a ForwardedHeaders Middleware , which reads headers such as X-Forwarded-Host and X-Forwarded-Proto. These headers replace values in HttpContext such as HttpContext.Request.Host and HttpContext.Request.Scheme. By passing these headers appropriately from IIS Reverse Proxy, we can resolve the redirect URI issue. But IIS reverse proxy or server farms doesn't send X-Forwarded-Host & X-Forwarded-Proto headers by default. You’ll need to configure IIS to include these headers using the URL Rewrite feature. To do so, follow these steps: Set Server Variables Open the URL Rewrite module in the IIS Manager Console and Select View Server Variables. Add following Server Variables: HTTP_X_Forwarded_Host HTTP_X_Forwarded_Proto Edit Inbound Rules Once Server Variables are added, select the concerned reverse proxy inbound rule and select Edit under Inbound rules in Actions Pane. Add the Server Variables to the inbound rule: Map HTTP_X_Forwarded_Host to {HTTP_HOST} Map HTTP_X_Forwarded_Proto to https Once IIS is configured to pass forwarded headers, the application needs to process them. Add ForwardedHeaders Middleware in your ASP.NET Core application and configure ForwardedHeadersOptions as follows: using Microsoft.AspNetCore.HttpOverrides; var builder = WebApplication.CreateBuilder(args); // Add services to the container. builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme) .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd")); builder.Services.AddAuthorization(options => { // By default, all incoming requests will be authorized according to the default policy. options.FallbackPolicy = options.DefaultPolicy; }); builder.Services.AddRazorPages() .AddMicrosoftIdentityUI(); builder.Services.Configure<ForwardedHeadersOptions>(options => { options.KnownProxies.Add(IPAddress.Parse("10.160.7.4")); // Reverse Proxy IP address options.ForwardedHeaders = ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedHost; }); var app = builder. Build(); app.UseForwardedHeaders(); // ForwardedHeaders Middleware // Configure the HTTP request pipeline. if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Error"); app.UseHsts(); } app.UseHttpsRedirection(); app.UseRouting(); app.UseAuthentication(); app.UseAuthorization(); app.MapStaticAssets(); app.MapRazorPages() .WithStaticAssets(); app.MapControllers(); app.Run(); Note: Order of the Middleware is important. Ensure ForwardedHeaders Middleware is called before any other middleware in the pipeline. Make sure to add the IP address of your ARR/IIS Reverse Proxy to the KnownProxies list. Alternatively, you can use KnownNetwork to set IP range. With these configurations, X-Forwarded-Host and X-Forwarded-Proto headers sent from IIS Reverse Proxy will replace the Host and Scheme in HttpContext. This ensures that the redirect URI correctly points to the IIS Reverse Proxy endpoint, resolving the issue seamlessly. Further Reading: Refer to these resources for more information: Configure ASP.NET Core to work with proxy servers and load balancers | Microsoft Learn Setting HTTP request headers and IIS server variables | Microsoft Learn IIS Server Variables | Microsoft Learn Hope this guide helps!
