In some STM32 models, USB PHY overrides the GPIO settings. This is undocumented and unacknowledged by ST, but has been reported here several times already, I'm lazy to look it up now. This may be the same case.
This stems from ST's inability to establish a solid nomenclature for the USB OTG modules and their PHY. In 'H7 datasheets (the pinmux table), they kinda' started in the right direction by marking them OTG1 and OTG2, but then they ignore this nomenclature in names of individual signals in the very same table. No wonder they also in CubeMX ignore this own nomenclature, adding more and more names, promoting further the confusion they introduced in earlier models.
In 'H743, OTG1 - which in CubeMX is apparently called USB_HS - can use both external ULPI (which traditionally is called HS but may be capable of FS, too) and its internal PHY for FS-only. PBere obviously chose using the internal PHY, as witnessed by DP/DM being assigned to PB14/PB15, leaving PB12 free - unless the 'H7 suffers from the plague of PHY overriding the GPIO settings (PB12 is OTG1 PHY's ID pin).
I configurated USB-OTG-HS with Internal FS Phy in Device_Only.
I did not set up PB12 ULPI-D5 manually. (But I checked the code if I will set up. Just in this case I saw PB12 setup for ULPI-D5 in USB config function.)
I checked the GPIO registers in Debug:
Before USB init: (PB12 initialised input-floating)
MODER.MODE12==0 -->INPUT
OTYPER.OT12==0 -->OUT PP (reset state)
PUPDR.PUPD12==0 -->FLOATING
IDR.IDR12==0 -->0V
ODR.ODR12==0 -->0V
LCKR.LCK12==0 -->NOT LOCKED
AFRH.AFSEL12==0 -->AF0
After USB init: (PB12 initialised input-floating -- excepd PB12 pin measured voltage:2.7V)
MODER.MODE12==0 -->INPUT
OTYPER.OT12==0 -->OUT PP (reset state)
PUPDR.PUPD12==0 -->FLOATING
IDR.IDR12==1 -->2.7V
ODR.ODR12==0 -->2.7V
LCKR.LCK12==0 -->NOT LOCKED
AFRH.AFSEL12==0 -->AF0
After USB init and reinitialise PB12: (PB12 initialised input-floating -- excepd measured voltage:2.7V)
Sorry, I neither like nor use STMcube ... I cannot give you answers on such detail questions ... STMcube has "deep and tricky dungeons" in the software, it is always difficult to judge what is happening there ... .
But I use USB-HS in HiSpeed mode together with much other peripherals ... and all running VERY nice - STMH7 is really a very nice controller family (STMcube free :)).
try to switch on the internal pulldown, and measure the output (don't need to write code, you can do it in the debugger alone); perhaps also try to attach an external pulldown, various values, try perhaps 10kOhm and 1kOhm
try to change the pin to GPIO Output and observe if it follows changes in ODR
try to disable USB's PHY (set OTG_GCCFG.PWRDWN to 0) and measure the pin's output
