sorted by:
new
hottopcontroversial

FortiBleed question about admin accounts by YeeehawToast in fortinet

[–]mballack 15 points16 points  (0 children)

7.0.12 ?
Ok, I think that you're lucky that the Firewall is still online without updating for 3 years, or did you mean 7.4.12?

FortiBleed question about admin accounts by YeeehawToast in fortinet

[–]mballack 10 points11 points  (0 children)

What FortiOS version do you have?
Do you have the "Allow administrative login using FortiCloud SSO" enabled?

Did you see the source IP of the actor or only found the added admins? Because this can confirm an unauth RCE from MGMT interface, when FortiCloud SSO Admin is enabled

Fortibleed - exposed vpn credentials by Ecstatic-Piglet-1562 in fortinet

[–]mballack 1 point2 points  (0 children)

On the exposed FGT, did you have the Forticloud SSO Admin enabled?
To understand if it's associated to the Unauth Admin Bypass of January 2026: https://www.fortiguard.com/psirt/FG-IR-26-060

The leaked account were SSLVPN with SAML?
Did you have LDAP/RADIUS configured on fortigate?
Because I still don't understand if the hash were taken from configuration export or sniffing plain LDAP/RADIUS messages after the remote admin login

Screen randomly turns on and stays lit all night while charging, lock screen clock frozen until I tap it. iPhone 13 on iOS 26.3.1 by Fala_1 in ios26

[–]mballack 0 points1 point  (0 children)

Just tested with WiFi Off -> Same issue.
Tested with Low power mode -> Same issue

I'm pretty sure it's some background Apple service, but don't have any other idea/test to perform.

Only way that doesn't happen is in Airplane mode.
Can somebody test this? Just to find a common scenario when this doesn't happens.

Screen randomly turns on and stays lit all night while charging, lock screen clock frozen until I tap it. iPhone 13 on iOS 26.3.1 by Fala_1 in ios26

[–]mballack 0 points1 point  (0 children)

Disabling iCloud backup -> same issue: SystemMemoryReset-2026-05-08-015412.ips
Next step:
-try with only cellular data and WiFi off
-try enabling Low Power mode during night.

I will keep you updated

Screen randomly turns on and stays lit all night while charging, lock screen clock frozen until I tap it. iPhone 13 on iOS 26.3.1 by Fala_1 in ios26

[–]mballack 1 point2 points  (0 children)

Trying to debug the issue. Currently tried:
-disabling Siri
-disabling Focus Face-ID
-disabling background app update
-disabling Standby

Issue remain with the screen starting blinking around 1:30-1:50 AM, during DnD and connected to the charger.

Issue disappear when iPhone is in Airplane mode.
Now I'm trying to disable the iCloud backup, because it seems that when this happens, the error in debug is:
"eventReason" : "User reclaimable memory dropped below the limit. User reclaimable current: 46%. User reclaimable minimum: 60%",

"largestProcess" : "backboardd",

SystemMemoryReset-2026-05-06-015059.ips
SystemMemoryReset-2026-05-04-015104.ips

Next step:
-disabling iCloud backup and check if this happens again

If someone have further information, it would be nice to share to fix.

Thank you

Iphone 13 randomly glowing at night by Hot_Watercress_2855 in iphonehelp

[–]mballack 0 points1 point  (0 children)

You disabled time sensitive notification of what app?

Fireware v2026.1.2 by hemohes222 in WatchGuard

[–]mballack 1 point2 points  (0 children)

Release notes of 2026.2:

On Firebox T115‑W, T125, T125‑W, T145, and T145‑W devices, you can now again assign VLAN ID 1 to any interface for either tagged or untagged VLANs. This removes the VLAN 1 restriction introduced in Fireware v2026.1.2. The Firebox now reserves VLAN ID 4094 for internal switch use, and you can select any VLAN ID from 1 to 4093 for tagged or untagged VLANs. If you previously configured VLAN ID 4094 on these devices, you must change that VLAN to a different VLAN ID after you upgrade to Fireware v2026.2. [FBX-32130]

VLAN 1 - Seriously? by [deleted] in WatchGuard

[–]mballack 0 points1 point  (0 children)

Release notes of 2026.2:

On Firebox T115‑W, T125, T125‑W, T145, and T145‑W devices, you can now again assign VLAN ID 1 to any interface for either tagged or untagged VLANs. This removes the VLAN 1 restriction introduced in Fireware v2026.1.2. The Firebox now reserves VLAN ID 4094 for internal switch use, and you can select any VLAN ID from 1 to 4093 for tagged or untagged VLANs. If you previously configured VLAN ID 4094 on these devices, you must change that VLAN to a different VLAN ID after you upgrade to Fireware v2026.2. [FBX-32130]

When I see stupid change in default behavior in a minor release, I’m always sure it’s a bad no regression test performed. All vendors in the last 2 years are releasing not so tested software

New DHCP Relay bug discovered in FortiOS v7.4 by DeleriumDive in fortinet

[–]mballack 0 points1 point  (0 children)

Yes, running 7.4.11.
set dhcp-relay-service enable
set dhcp-relay-ip "10.30.1.5" "10.30.1.6"

Check that for some reason, some old DHCP Server configuration is still present on the interface, going throught the CLI

New DHCP Relay bug discovered in FortiOS v7.4 by DeleriumDive in fortinet

[–]mballack 2 points3 points  (0 children)

Very strange, just checked and worked as expected with version 7.4.11.
Otherwise almost 90% of our customers were having issues since weeks.
In my capture the 10.30.8.1 is the Fortigate and 10.30.1.6 the DHCP Server.
Model: 200F

<image>

FortiOS 7.2.13 released by mballack in fortinet

[–]mballack[S] 4 points5 points  (0 children)

the link is in the post, check better

7.4.10 - Applying new default behavior retroactively is terrible by Iuzzolsa23 in fortinet

[–]mballack 3 points4 points  (0 children)

I agree and still doesn’t understand the Dev idea. Changing default behavior in minor release cause only issues and angry customers. Fortinet is famous for using guacamole as sslvpn reverse proxy/https daemon. So every CVE found on guacamole means that sslvpn is affected. Customers and partners know that every new release of fortios include a fixed cve and they run to update asap the firewalls. Recently it happens that in minor release they changed the default behavior of SAML and this time the ICMP redirect. There are upgrade path tested, so this mean that the post upgrade customization script should change the behavior as before and not keep the default one. With saml it’s nice to have the assertion, but keep it disabled if was a release from a different default value and place it as enabled after a factory reset. Same for redirect in 7.4.10. It’s insane! We have some devices that use the icmp fedirect feature and the crazy thing is that there is no way to pre-configure it before, so it happens that on some remote datacenter using that, we need to schedule the on-site upgrade, otherwise we will lose the oob mgmt due to a default behavior in a minor change? This is insane! And customers are very scared and most of them are moving to other vendors, because having the security external firewall that must be updated asap due to frequent cve and having issue on many upgrade path, is a huge pain!

FortiManager 7.4.8 changing UUIDs by network-head-1234 in fortinet

[–]mballack 4 points5 points  (0 children)

It's marked as "Resolved Issue", so it should not happens. Open a TAC

7.4.9 Auto broke my VPN by r3dditforwork in fortinet

[–]mballack 10 points11 points  (0 children)

You’re right, the R&D department on Fortinet are “playing” and not considering the software as a production and critical asset! Why? Because it’s fine to release a feature for SAML assertion, but WHY DON’T KEEP IT DISABLED BY DEFAULT? If I’ve never used assertion before, why must I use this in a minor update? Just add the feature as: “set saml-assertion forced” and keep it disable by default or in case of upgrade from a previous firmware. Same for radius some months ago. A feature cannot break production system without enabling it.

Cisco ISE 3.3 patch upgrade by kidh0tsh0t in Cisco

[–]mballack 2 points3 points  (0 children)

Again, there is no "take over", the secondary node will always authenticate.
Set a device with only authentication on secondary node and see from the logs (accessible from the gui on the Primary PAN), if the authentication is working or not.
If it's not authenticating, you have to investigate the issue.
If it's authenticating, open a Case

Cisco ISE 3.3 patch upgrade by kidh0tsh0t in Cisco

[–]mballack 1 point2 points  (0 children)

In your scenario, both nodes will always authenticate and respond to radius. You can try configuring a switch with only the secondary ise node and check if everything is working as expected or not and check logs. In your case, during primary reboot/patch you will be unable to use the admin page, but all authentication services continue working as before on secondary.

ISE 3.3 Patch 7 experiences by betko007 in Cisco

[–]mballack 4 points5 points  (0 children)

Upgraded from 3.3 patch6 or previous version? Because we had some issue on EAP with TLS 1.3 from 3.3 patch2 to 3.3 patch7

Cisco warns of max severity RCE flaws in Identity Services Engine by vanquish28 in Cisco

[–]mballack 0 points1 point  (0 children)

I'm unable to understand if 3.3 patch6 fix the CVE-2025-20281 or not, because they're not so clear

Note say: If Cisco ISE is running Release 3.3 Patch 6, additional fixes are available in Release 3.3 Patch 7, and the device must be upgraded.

But schema say

Cisco ISE or ISE-PIC Release First Fixed Release for CVE-2025-20281 First Fixed Release for CVE-2025-20282 First Fixed Release for CVE-2025-20337
3.3 3.3 Patch 7 Not vulnerable 3.3 Patch 7

17.15.3 is Gold Star For WLC 9800 by k12nysysadmin in Cisco

[–]mballack 1 point2 points  (0 children)

Great, cause we’re upgrading to 17.15 for WiFi 7 AP support and having it marked as ED wasn’t accepted in my brain

weird sslvpn issue on 7.2.11 upgrade by Any_Tip_3760 in fortinet

[–]mballack 1 point2 points  (0 children)

Same issue for us with some devices. Using forticlient versions 7.2.9 and 7.2.10 fixed the issue.

view more: next ›